[jira] Created: (MINSTALL-40) install with classifier with no target/classes fails
install with classifier with no target/classes fails Key: MINSTALL-40 URL: http://jira.codehaus.org/browse/MINSTALL-40 Project: Maven 2.x Install Plugin Issue Type: Bug Affects Versions: 2.2, 2.1 Environment: Maven version: 2.0.5, Winx XP pro Reporter: Michele Lorenzini Priority: Minor Attachments: sample-war.zip The install plugin fails with the following error: Error installing artifact: File C:\TEMP\sample-war\target\classes does not exist in a project where there is no class or classpath resource generation (so the target/classes folder is not generated in the compile phase). Suppose for example a war application with no java source code (maybe only jar dependencies) and no classpath resource. Installing the project as a primary artifact works fine. Installing the project as a secondary artifact (so with "classifier" option) with classes or resources works fine. Installing the project as a secondary artifact without classes or resources gives the error below. Attached is a simple project with packaging WAR composed only by a web.xml file. Running "mvn install" on this project should give the error above. Commenting the classifier tag will result in a successful install. Also if I put a simple java file (or a resource) the compile goal will create target/classes folder and the install works fine. In fact I am using this kind of workaround for the moment (include a dummy resource in the war build). The same is with a similar jar project (although it may be less useful to have an "empty" jar artifact). Verified with both maven-install-plugin 2.1 and 2.2 -- 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: (ARCHETYPE-59) archetype plugin doesn't use private plugin repository configured in /conf/settings.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103839 ] William Ferguson commented on ARCHETYPE-59: --- The workaround for this is to specify a 'remoteRepositories' property on the command line pointing to your internal Repository. Eg mvn archetype:create -DgroupId=com.yarris -DartifactId=foo-project -DarchetypeGroupId=com.yarris.maven -DarchetypeArtifactId=archetype-standard -DremoteRepositories=http://zosma.oz.hubbub.com.au:8080/proximity/repository/release This issues appears to be a duplicate of : http://jira.codehaus.org/browse/ARCHETYPE-1 http://jira.codehaus.org/browse/ARCHETYPE-81 What I don't understand is that http://jira.codehaus.org/browse/ARCHETYPE-1 is marked as closed fixed (with no version), but the issue still clearly exists in maven-2.0.7, maven-archetype-1.0-alpha-4 Without a real fix for this issue creating projects using archetypes is not really viable. Ie it becomes almost as easy to copy and paste an existing project and modify ts details that to use an archetype. Which is what I thought we are trying to get away from. > archetype plugin doesn't use private plugin repository configured in > /conf/settings.xml > --- > > Key: ARCHETYPE-59 > URL: http://jira.codehaus.org/browse/ARCHETYPE-59 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 1.0-alpha-4 > Environment: windows xp > jdk 1.5.0_09-b01 >Reporter: Martin Testrot > > I configured the file /conf/settings to use a local, private > plugin repository to prevent uncontrolled download from the official central > repository at http://repo1.maven.org/maven2. This works fine except in the > case I call the archetype plugin (archetype:create). In this case the > settings.xml is ignored and all plugins are downloaded from the central > repository at maven.org. > I observed the same when calling mvn help:active-profiles in a directory that > doesn't contain a pom.xml file. > If I place a dummy pom.xml file in this directory the settings.xml are used > and everything is fine. But if I use this trick with the archetype plugin the > newly created project (creation via archetype) is configured as a child of my > dummy pom (pom.xml contains parent section with dummy pom). I the case of a > dummy pom this is not intended. > So i would be nice if you can fix the archtype plugin to use the configured > settings.xml. I really would like to use this plugin, because it would help a > lot to standardize a common project layout for our developers. This is a > majour reason for choosing maven2. > Greetings, > Martin > Here is the relevant section of my settings.xml: > ... > > > > private-repo > > > > central > private plugin repository > > http://localserver/mvn-repos/maven-plugin > > true > > daily > > > false > > > > > > > > private-repo > > ... -- 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-2943) Same package name is used in different modules
[ http://jira.codehaus.org/browse/MNG-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2943. - Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) current status is won't fix > Same package name is used in different modules > -- > > Key: MNG-2943 > URL: http://jira.codehaus.org/browse/MNG-2943 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Carlos Sanchez > > As best practice and to play well with OSGi the same package shouldn't be in > two modules > We should copy classes to a new package, make old ones extend them and > deprecate -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2943) Same package name is used in different modules
[ http://jira.codehaus.org/browse/MNG-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2943: --- > Same package name is used in different modules > -- > > Key: MNG-2943 > URL: http://jira.codehaus.org/browse/MNG-2943 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.1-alpha-1 >Reporter: Carlos Sanchez >Assignee: Carlos Sanchez > > As best practice and to play well with OSGi the same package shouldn't be in > two modules > We should copy classes to a new package, make old ones extend them and > deprecate -- 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-2511) Need ability to redefine distribution management url
[ http://jira.codehaus.org/browse/MNG-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2511. - Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) fixed in deploy plugin instead > Need ability to redefine distribution management url > > > Key: MNG-2511 > URL: http://jira.codehaus.org/browse/MNG-2511 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4 >Reporter: Brian Fox > > Currently the only way to specify a url for distributionManagement is in the > pom. We need to be able to override that so that if needed a developer can > set a server id in their settings and define a new url. For example, some > developers are outside the company's infrastructure and they deploy > differently than developers internally. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MEV-542) Checksums For http://ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/maven-metadata.xml does not match
[ http://jira.codehaus.org/browse/MEV-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2563 to MEV-542: --- Priority: (was: Major) Fix Version/s: (was: Reviewed Pending Version Assignment) Complexity: (was: Intermediate) Workflow: jira (was: Maven New) Key: MEV-542 (was: MNG-2563) Project: Maven Evangelism (was: Maven 2) > Checksums For > http://ibiblio.org/maven2/org/apache/maven/plugins/maven-war-plugin/maven-metadata.xml > does not match > --- > > Key: MEV-542 > URL: http://jira.codehaus.org/browse/MEV-542 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Stephen Duncan Jr > > The checksum for the maven-metadata file does not match the file, causing > checksum errors (including Maven Archiva proxy not downloading the war 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] Reopened: (MNG-2511) Need ability to redefine distribution management url
[ http://jira.codehaus.org/browse/MNG-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2511: --- > Need ability to redefine distribution management url > > > Key: MNG-2511 > URL: http://jira.codehaus.org/browse/MNG-2511 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: Reviewed Pending Version Assignment > > > Currently the only way to specify a url for distributionManagement is in the > pom. We need to be able to override that so that if needed a developer can > set a server id in their settings and define a new url. For example, some > developers are outside the company's infrastructure and they deploy > differently than developers internally. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNGSITE-21) External link to jetty plugin info now invalid
[ http://jira.codehaus.org/browse/MNGSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3101 to MNGSITE-21: -- Affects Version/s: (was: Documentation) Fix Version/s: (was: Documentation) Component/s: (was: Sites & Reporting) Key: MNGSITE-21 (was: MNG-3101) Project: Maven Project Web Site (was: Maven 2) > External link to jetty plugin info now invalid > -- > > Key: MNGSITE-21 > URL: http://jira.codehaus.org/browse/MNGSITE-21 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Gwyn Evans >Assignee: Dennis Lundberg >Priority: Minor > > On the http://maven.apache.org/plugins/index.html page, the "jetty" link is > http://jetty.mortbay.org/maven-plugin/howto.html but that now gives 404 - It > looks to me as if it should now point to > http://jetty.mortbay.org/maven-plugin/index.html or > http://jetty.mortbay.org/maven-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] Moved: (MNGSITE-20) xml mistake in docs
[ http://jira.codehaus.org/browse/MNGSITE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3094 to MNGSITE-20: -- Fix Version/s: (was: Documentation) Component/s: (was: Documentation: Guides) Key: MNGSITE-20 (was: MNG-3094) Project: Maven Project Web Site (was: Maven 2) > xml mistake in docs > --- > > Key: MNGSITE-20 > URL: http://jira.codehaus.org/browse/MNGSITE-20 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: [EMAIL PROTECTED] >Assignee: Dennis Lundberg > > This xml example > > > my-internal-site > http://myserver/repo > > > On this page, > http://maven.apache.org/guides/introduction/introduction-to-repositories.html > Is not valid The second should read > As a second note. the error that maven reports seems to be a schema > validation error, > org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. > Reason: Unrecognised tag: 'repository' (position: START_TAG see > n ...\n ... @32:18) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > It would be more useful if you did encounter an error, to report well > formededness exceptions first. If the error had said something like missing > end tag, I would know what the problem was right away. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MRESOURCES-45) Abstract resource filtering into Plexus
[ http://jira.codehaus.org/browse/MRESOURCES-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2065 to MRESOURCES-45: - Fix Version/s: (was: 2.2.x) 2.3 Component/s: (was: Plugins and Lifecycle) Complexity: (was: Intermediate) Key: MRESOURCES-45 (was: MNG-2065) Project: Maven 2.x Resources Plugin (was: Maven 2) > Abstract resource filtering into Plexus > --- > > Key: MRESOURCES-45 > URL: http://jira.codehaus.org/browse/MRESOURCES-45 > Project: Maven 2.x Resources Plugin > Issue Type: Improvement >Reporter: Brian Topping >Priority: Minor > Fix For: 2.3 > > Attachments: mng-2065.patch > > > ResourcesMojo has capacity for doing resource filtering. This functionality > is useful in other parts of the source tree, and rather than duplicate it, I > abstracted the functionality into Plexus FileUtils. > Attached is a patch for ResourcesMojo to use this new functionality. If you > have svn trunk from Plexus, this code will work. I do not understand the > versioning and dependency changes that are required for this, so I left those > patches out. For my part in it, I did a version override to get things to > compile. > I'll get the web filtering done shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-5) pretty resources addition
[
http://jira.codehaus.org/browse/MNG-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter reopened MNG-5:
> pretty resources addition
> -
>
> Key: MNG-5
> URL: http://jira.codehaus.org/browse/MNG-5
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: gilles dodinet
> Fix For: 2.1.x
>
>
> adding resources to pom should merge similar resources if possible (not
> conflicting). f.i. if resource.directory=D and includes.contains("**/*") all
> resources such as resource.directory=D should be removed, otherwise(if not
> conflicting) includes should be merged.
--
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-5) pretty resources addition
[
http://jira.codehaus.org/browse/MNG-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-5.
--
Resolution: Won't Fix
believe this was not fixed, setting to won't fix instead
> pretty resources addition
> -
>
> Key: MNG-5
> URL: http://jira.codehaus.org/browse/MNG-5
> Project: Maven 2
> Issue Type: Improvement
> Components: POM
>Reporter: gilles dodinet
> Fix For: 2.1.x
>
>
> adding resources to pom should merge similar resources if possible (not
> conflicting). f.i. if resource.directory=D and includes.contains("**/*") all
> resources such as resource.directory=D should be removed, otherwise(if not
> conflicting) includes should be merged.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-574) Add version info to plugins.xml and cache that in plugin-registry.xml
[ http://jira.codehaus.org/browse/MNG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-574: -- > Add version info to plugins.xml and cache that in plugin-registry.xml > - > > Key: MNG-574 > URL: http://jira.codehaus.org/browse/MNG-574 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Kenney Westerhof >Priority: Minor > > By caching that information locally, maven only has to check one url to see > if a plugin is up-to-date, rather than open a > connection for each plugin encountered. -- 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-574) Add version info to plugins.xml and cache that in plugin-registry.xml
[ http://jira.codehaus.org/browse/MNG-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-574. Resolution: Won't Fix Fix Version/s: (was: 2.1.x) > Add version info to plugins.xml and cache that in plugin-registry.xml > - > > Key: MNG-574 > URL: http://jira.codehaus.org/browse/MNG-574 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Kenney Westerhof >Priority: Minor > > By caching that information locally, maven only has to check one url to see > if a plugin is up-to-date, rather than open a > connection for each plugin encountered. -- 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: (MNG-1634) move maven-core-it to integration-tests
[ http://jira.codehaus.org/browse/MNG-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1634: -- Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > move maven-core-it to integration-tests > --- > > Key: MNG-1634 > URL: http://jira.codehaus.org/browse/MNG-1634 > Project: Maven 2 > Issue Type: Task > Components: Bootstrap & Build, Design, Patterns & Best Practices >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > we should first change the bootstrap to run the integration tests as part of > the bootstrap, against the prebuild rather than the final M2_HOME installation -- 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: (MNG-1849) maven-model Extension.hashCode() throws NPE if groupId or artifactId is null
[ http://jira.codehaus.org/browse/MNG-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1849: -- Fix Version/s: (was: 2.1.x) 2.0.7 > maven-model Extension.hashCode() throws NPE if groupId or artifactId is null > - > > Key: MNG-1849 > URL: http://jira.codehaus.org/browse/MNG-1849 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 >Reporter: David Hawkins > Fix For: 2.0.7 > > Attachments: MNG-1849-maven-model.patch > > > org.apache.maven.model.Extension.hashCode() throws NullPointerException if > the groupId or artifactId is null. > There was null checking on version, but not on groupId or artifactId so this > patch adds it. -- 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: (MNG-611) improve independence of plugins from core
[ http://jira.codehaus.org/browse/MNG-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-611: - Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > improve independence of plugins from core > - > > Key: MNG-611 > URL: http://jira.codehaus.org/browse/MNG-611 > Project: Maven 2 > Issue Type: Task >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > currently, the coupling of the plugins is often very tightly related to the > core, which can cause a problem if the API changes and the plugins are to be > used across versions. > we should look to: > 1) separate the classloaders as much as possible (see other issue) > 2) try and minimise and stabilise the public API of those being used > (artifact, project, plugin-api most notably) > 3) reduce use of Maven dependencies where possible > 4) look at the expressions available and see if too much is exposed -- 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: (MNG-655) don't load extensions into the main container
[ http://jira.codehaus.org/browse/MNG-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-655: - Fix Version/s: (was: 2.1.x) 2.0.5 > don't load extensions into the main container > - > > Key: MNG-655 > URL: http://jira.codehaus.org/browse/MNG-655 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 2.0.5 > > Original Estimate: 8 hours > Remaining Estimate: 8 hours > > this should be done on a project by project basis - currently, they are all > loaded into the main container. -- 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: (MNG-2015) create an inter-plugin communication bus, for setting flags about the generalized build state
[
http://jira.codehaus.org/browse/MNG-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-2015:
--
Fix Version/s: (was: 2.1.x)
2.1-alpha-1
> create an inter-plugin communication bus, for setting flags about the
> generalized build state
> -
>
> Key: MNG-2015
> URL: http://jira.codehaus.org/browse/MNG-2015
> Project: Maven 2
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.2
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.1-alpha-1
>
>
> Currently, there is no way for mojos in different plugins to communicate with
> one another in any way, other than flag files written into someplace like
> ${project.build.directory}.
> We need a communication bus by which plugins can communicate build state with
> one another. This communication can be limited, both in terms of legal values
> (allow only Strings?), and in terms of the messages that can be sent (eg.
> "compile" phase ran == Boolean.TRUE or something).
> Such communication can greatly enhance Maven's ability to optimize builds,
> and only perform the steps necessary to respond to changes since the last
> build, where possible.
--
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: (MNG-1259) clean up/fix the plugin registry
[ http://jira.codehaus.org/browse/MNG-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1259: -- Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > clean up/fix the plugin registry > > > Key: MNG-1259 > URL: http://jira.codehaus.org/browse/MNG-1259 > Project: Maven 2 > Issue Type: Task > Components: Plugins and Lifecycle, Settings >Affects Versions: 2.0-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > there are some command line options left over that are ineffective since the > plugin registry isn't really used. We need to ensure this whole thing is > fixed up, reenabled and cleaned up -- 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: (MNG-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1832: -- Fix Version/s: (was: 2.1.x) > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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: (MNG-2767) Use MiniJAR to crush the final assembly down and munge package dependencies
[ http://jira.codehaus.org/browse/MNG-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2767: -- Affects Version/s: (was: 2.1.x) 2.1-alpha-1 Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > Use MiniJAR to crush the final assembly down and munge package dependencies > --- > > Key: MNG-2767 > URL: http://jira.codehaus.org/browse/MNG-2767 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1-alpha-1 >Reporter: Jason van Zyl > Fix For: 2.1-alpha-1 > > > This would reduce the size of the final assembly and munge the use of any > util code like plexus utils so that plugins will never be stuck using the > same version that is used as a core 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] Updated: (MNG-4) MavenXpp3Writer improvement
[ http://jira.codehaus.org/browse/MNG-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4: --- Fix Version/s: (was: 2.1.x) > MavenXpp3Writer improvement > --- > > Key: MNG-4 > URL: http://jira.codehaus.org/browse/MNG-4 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Reporter: gilles dodinet > > It would great if the writer would remember the structure of the file (if > already exists) to keep comments and formatting so that user is not lost when > reopening the file. Milos has written that, altho with jdom. > please see > http://cvs.mevenide.codehaus.org/cvsweb.cgi/mevenide-core/src/java/org/mevenide/project/io/CarefulProjectMarshaller.java?rev=1.4 -- 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: (MNG-1940) In maven-core-it, all integration test projects should have unique artifactId
[ http://jira.codehaus.org/browse/MNG-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1940: -- Fix Version/s: (was: 2.1.x) 2.1-alpha-1 > In maven-core-it, all integration test projects should have unique artifactId > - > > Key: MNG-1940 > URL: http://jira.codehaus.org/browse/MNG-1940 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.0.2 >Reporter: Allan Ramirez > Fix For: 2.1-alpha-1 > > Attachments: MNG-1940.patch > > > The artifact Id of it0038 is the same with it0037 and it0052 to it0051 -- 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-1448) Easy way to tell if the plugin is for m2 or m1
[ http://jira.codehaus.org/browse/MNG-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1448. - Resolution: Won't Fix Fix Version/s: (was: 2.1.x) > Easy way to tell if the plugin is for m2 or m1 > -- > > Key: MNG-1448 > URL: http://jira.codehaus.org/browse/MNG-1448 > Project: Maven 2 > Issue Type: Bug >Reporter: Alexandre Poitras > -- 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-2220) ${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized
[
http://jira.codehaus.org/browse/MNG-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2220.
-
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.1.x)
> ${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer
> recognized
> --
>
> Key: MNG-2220
> URL: http://jira.codehaus.org/browse/MNG-2220
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.4
> Environment: n/a
>Reporter: Marcel Schutte
> Attachments: buglet.zip
>
>
> The properties ${pom.build.sourceDirectory} and
> ${pom.build.testSourceDirectory} (and perhaps others as well) are no longer
> recognized in pom.xml. The following pom fragment had the desired effect of
> copying resources from the sourceDirectory in version 2.0.3, but doesn't work
> in 2.0.4:
>
> src
> src-test
>
>
> ${pom.build.sourceDirectory}
>
> **/*.properties
>
>
>
>
>
> ${pom.build.testSourceDirectory}
>
> **/mockfiles/
>
>
>
> The attached project will fail on a 'mvn test' under maven 2.0.4 and succeed
> under 2.0.3
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2220) ${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized
[
http://jira.codehaus.org/browse/MNG-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter reopened MNG-2220:
---
> ${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer
> recognized
> --
>
> Key: MNG-2220
> URL: http://jira.codehaus.org/browse/MNG-2220
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.4
> Environment: n/a
>Reporter: Marcel Schutte
> Attachments: buglet.zip
>
>
> The properties ${pom.build.sourceDirectory} and
> ${pom.build.testSourceDirectory} (and perhaps others as well) are no longer
> recognized in pom.xml. The following pom fragment had the desired effect of
> copying resources from the sourceDirectory in version 2.0.3, but doesn't work
> in 2.0.4:
>
> src
> src-test
>
>
> ${pom.build.sourceDirectory}
>
> **/*.properties
>
>
>
>
>
> ${pom.build.testSourceDirectory}
>
> **/mockfiles/
>
>
>
> The attached project will fail on a 'mvn test' under maven 2.0.4 and succeed
> under 2.0.3
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-1448) Easy way to tell if the plugin is for m2 or m1
[ http://jira.codehaus.org/browse/MNG-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-1448: --- > Easy way to tell if the plugin is for m2 or m1 > -- > > Key: MNG-1448 > URL: http://jira.codehaus.org/browse/MNG-1448 > Project: Maven 2 > Issue Type: Bug >Reporter: Alexandre Poitras > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNGSITE-19) Reformatted Guides List
[ http://jira.codehaus.org/browse/MNGSITE-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2622 to MNGSITE-19: -- Fix Version/s: (was: 2.0.x) Component/s: (was: Documentation: Guides) Complexity: (was: Intermediate) Key: MNGSITE-19 (was: MNG-2622) Project: Maven Project Web Site (was: Maven 2) > Reformatted Guides List > --- > > Key: MNGSITE-19 > URL: http://jira.codehaus.org/browse/MNGSITE-19 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Eric Redmond >Priority: Trivial > Attachments: guides_list.patch > > > Reformatting the existing guides list to split the guides into a more > thematic hierachy, reducing large groupings of documents. > Example: > http://www.propellors.net/maven/site/guides/index.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] Closed: (MNG-939) specify maven settings from command line
[ http://jira.codehaus.org/browse/MNG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-939. Resolution: Won't Fix Fix Version/s: (was: 2.0.x) > specify maven settings from command line > > > Key: MNG-939 > URL: http://jira.codehaus.org/browse/MNG-939 > Project: Maven 2 > Issue Type: Improvement > Components: Design, Patterns & Best Practices >Affects Versions: 2.0-beta-1 > Environment: All >Reporter: Guest >Priority: Trivial > Attachments: MNG-939-maven-core.patch > > > Would like to be able to specify my server password at the command line, for > the server configured in the settings.xml file as I'm not happy embedding it > there or permanently giving my computer access via a certificate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-939) specify maven settings from command line
[ http://jira.codehaus.org/browse/MNG-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-939: -- > specify maven settings from command line > > > Key: MNG-939 > URL: http://jira.codehaus.org/browse/MNG-939 > Project: Maven 2 > Issue Type: Improvement > Components: Design, Patterns & Best Practices >Affects Versions: 2.0-beta-1 > Environment: All >Reporter: Guest >Priority: Trivial > Attachments: MNG-939-maven-core.patch > > > Would like to be able to specify my server password at the command line, for > the server configured in the settings.xml file as I'm not happy embedding it > there or permanently giving my computer access via a certificate. -- 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: (MNG-2607) Cycle in plugins build
[
http://jira.codehaus.org/browse/MNG-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-2607:
--
Fix Version/s: (was: 2.0.x)
> Cycle in plugins build
> --
>
> Key: MNG-2607
> URL: http://jira.codehaus.org/browse/MNG-2607
> Project: Maven 2
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 2.0.5
>Reporter: Eric Redmond
>
> I just bootstrapped 2.0.5-SNAP and attempted to build plugins from scratch.
> The following cycle ensued:
> The projects in the reactor contain a cyclic reference: Edge between
> 'Vertex{label='org.apache.maven.plugins:maven-javadoc-plugin'}' and
> 'Vertex{label='org.apache.maven.plugins:maven-checkstyle-plugin'}' introduces
> to cycle in the graph org.apache.maven.plugins:maven-checkstyle-plugin -->
> org.apache.maven.plugins:maven-javadoc-plugin -->
> org.apache.maven.plugins:maven-checkstyle-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] Updated: (MNG-3050) [maven-plugin-testing-harness] Implement ArtifactStub.getDependencyConflictId
[ http://jira.codehaus.org/browse/MNG-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3050: -- Fix Version/s: (was: 2.0.x) Shared Components > [maven-plugin-testing-harness] Implement ArtifactStub.getDependencyConflictId > - > > Key: MNG-3050 > URL: http://jira.codehaus.org/browse/MNG-3050 > Project: Maven 2 > Issue Type: Bug > Components: Shared >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: Shared Components > > Attachments: patch.txt > > > Return a simple dependency conflict id in ArtifactStub since this is never > null in DefaultArtifact and can cause NPEs in tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1889) Plugins without descriptors
[ http://jira.codehaus.org/browse/MNG-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1889: -- Fix Version/s: (was: 2.0.x) 2.0.7 > Plugins without descriptors > --- > > Key: MNG-1889 > URL: http://jira.codehaus.org/browse/MNG-1889 > Project: Maven 2 > Issue Type: Bug > Components: Plugin Creation Tools >Affects Versions: 2.0.1 >Reporter: Jochen Wiedmann >Priority: Minor > Fix For: 2.0.7 > > Attachments: maven-no-plugin-descriptors.patch, > numMojoDescriptors.patch > > > The attached patch throws an exception, if no Mojos are found in a plugin. > Background: If such a plugin is installed, then an NPE is caused in the > DefaultLifeCycleExecutor, which properly assumes, that a plugin contains Mojo > descriptors. Obviously, the actual error is in the plugin itself, where it > should be exposed. It took me some hours to find this actual reason. (I still > do not know, why the Mojos aren't found in my plugin, but that's another > story.) The patch should be able to save the same number of hours for other > plugin developers. > Note: The InvalidPluginDescriptorException, which is triggered by the patch, > is possibly not proper. I choosed it, because it allowed to leave the method > signature unchanged and keep the patch simple. It is up to the reviewer to > choose another exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNGSITE-18) Nabble Links to Docs and LHS menu
[ http://jira.codehaus.org/browse/MNGSITE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2641 to MNGSITE-18: -- Fix Version/s: (was: 2.0.x) Component/s: (was: Documentation: Guides) Complexity: (was: Intermediate) Key: MNGSITE-18 (was: MNG-2641) Project: Maven Project Web Site (was: Maven 2) > Nabble Links to Docs and LHS menu > - > > Key: MNGSITE-18 > URL: http://jira.codehaus.org/browse/MNGSITE-18 > Project: Maven Project Web Site > Issue Type: New Feature >Reporter: Eric Redmond >Priority: Trivial > Attachments: nabble_links.patch > > > A patch to add nabble forum link to the site.xml file of the main maven site, > added link to community.apt, and squeezed in a minor fix to the site.css file. -- 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: (MNG-1910) Allow jdk 1.4+ as profile requirement
[ http://jira.codehaus.org/browse/MNG-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1910: -- Fix Version/s: (was: 2.0.x) 2.0.7 > Allow jdk 1.4+ as profile requirement > - > > Key: MNG-1910 > URL: http://jira.codehaus.org/browse/MNG-1910 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.1 >Reporter: Jochen Wiedmann > Fix For: 2.0.7 > > Attachments: jdk_plus.patch, jdk_plus.patch > > > The "jdk" element in the POM allows for strings like "1.5", or "!1.4" only. > It would be desirable to use "1.4+", or something similar. The attached patch > serves that purpose. > A patch for the docs is missing. I am ready to create such a patch as well, > if I know that my idea would be accepted. -- 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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103835
]
Joerg Schaible commented on MNG-2290:
-
If the URL is not inherited, you must define it in any child POM anyway, so
your comments make not much sense to me. For me the only useful default is the
path that was chosen in the SCM. This applies also if you add the version to
the path.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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-441) removing a "remote repository" should not present the page about handling content
[ http://jira.codehaus.org/browse/MRM-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-441: - Fix Version/s: 1.0-beta-2 > removing a "remote repository" should not present the page about handling > content > - > > Key: MRM-441 > URL: http://jira.codehaus.org/browse/MRM-441 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Brett Porter > Fix For: 1.0-beta-2 > > > eg. delete the default java.net repository when starting a new installation. > Expected result: a confirmation page (yes/no only) about whether to remove it > Actual result: the normal managed repository page about deleting the > repository definition, contents, or going back -- 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-441) removing a "remote repository" should not present the page about handling content
removing a "remote repository" should not present the page about handling content - Key: MRM-441 URL: http://jira.codehaus.org/browse/MRM-441 Project: Archiva Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Brett Porter Fix For: 1.0-beta-2 eg. delete the default java.net repository when starting a new installation. Expected result: a confirmation page (yes/no only) about whether to remove it Actual result: the normal managed repository page about deleting the repository definition, contents, or going back -- 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-440) If webdav URL lacks a trailing /, navigating to all links in the listing return 404.
[ http://jira.codehaus.org/browse/MRM-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-440: - Fix Version/s: 1.0.x > If webdav URL lacks a trailing /, navigating to all links in the listing > return 404. > > > Key: MRM-440 > URL: http://jira.codehaus.org/browse/MRM-440 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0.x > > > If you go to: > http://localhost:8080/archiva/repository/releases > then click a link, you get 404. > But if you go to: > http://localhost:8080/archiva/repository/releases/ > everything works as expected. -- 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-440) If webdav URL lacks a trailing /, navigating to all links in the listing return 404.
If webdav URL lacks a trailing /, navigating to all links in the listing return 404. Key: MRM-440 URL: http://jira.codehaus.org/browse/MRM-440 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0-alpha-2 Reporter: Brett Porter Priority: Minor Fix For: 1.0.x If you go to: http://localhost:8080/archiva/repository/releases then click a link, you get 404. But if you go to: http://localhost:8080/archiva/repository/releases/ everything works as expected. -- 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: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103824
]
William Ferguson commented on ARCHETYPE-39:
---
For those interested in a solution, specify
#set($dollar = '$')
at the head of the archetype Velocity template in which you need the unescaped
dollar signs.
Then to get ${artifactId} in the output, specify
${dollar}{artifactId}
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103823
]
William Ferguson commented on ARCHETYPE-39:
---
OK, I'm confused.
The issue is marked as WON'T FIX, but the comment seem to imply that a change
was made.
Was a change made and if so which version of the archetype-plugin?
Also, what is the syntax that is required to get it to work?
Wendy's comment on 2-JUN-07 seem to imply that ${artifactId} in the archetype
will produce ${artifactId} in the new project, but that doesn't work for me
with maven-2.0.7 and maven-archetype-1.0-alpha-4.
Tokens of the form ${artifactId} are converted to actual values when creating
the new project.
Just like Guillaume, I need ${artifactId} in the output.
How do I get it?
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103822
]
William Ferguson commented on MNG-2290:
---
The work around for this is top specify the project#url and
project#distributionManangement#site#url in *every* POM.
Failure to do so means that :
If your parent POM defines its URLs as http://MyMachine/projects then the child
projects will be published to reachable (but unversioned) locations such as
http://MyMachine/projects/SomeProject on the projects site, but the site for
the parent POM will be published to the root of your projects site, generally
overwriting any general welcome page that might direct you to the other
projects.
If your parent POM defines its URLs as http://MyMachine/projects/${artifactId}
then the child projects will be published to locations such as
http://MyMachine/projects/SomeProject/SomeProject but the parent POM will get
published to an expected location like http://MyMachine/projects/MyPom.
So there is also inconsistency between a URL defined in a POM and one defined
in a parent POM.
Please, please make it consistent, preferably by having no automatic appending
of the artifactId for URLs defined in a parent POM and instead let us specify
the location using build properties like
http://MyMachine/projects/${artifactId}/${version} which are evaluated just
like every other build property. The current behaviour is inconsistent with
every other aspect of a Maven build.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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-1660) Please upload EZMorph-1.0.3
Please upload EZMorph-1.0.3 --- Key: MAVENUPLOAD-1660 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1660 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray EZMorph is simple java library for transforming an Object to another Object. This release covers minor enhancements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2290) Generated URLs in POMs of child modules
[ http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92415 ] William Ferguson edited comment on MNG-2290 at 8/1/07 6:35 PM: --- It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http://MyMachine/svn/MyProject/trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. was: It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http:///svn/ /trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. > Generated URLs in POMs of child modules > --- > > Key: MNG-2290 > URL: http://jira.codehaus.org/browse/MNG-2290 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 >Reporter: Joerg Schaible > Fix For: 2.0.x > > > Maven has quite some elements where a URL or a path is modified automatically > for child POMs (the ones I am currently aware of): > - url > - scm/connection > - scm/developerConnection > - scm/url > - distributionManagement/site/url > While expanding this path with "/${pom.artifactId}" sounds reasonable, this > approach fails badly for complex projects with more hierarchy levels. Suppose > we have a directory structure like: > * project > ** core > *** provider > commons > impl1 > In this hierarchy all POMs for _project_, _core_ and _provider_ are of > package type _pom_, while _commons_ and _impl1_ is of type _jar_. The > "artifactId" approach now simply assumes that all POMs in the hierarchy are > named like the current directory. This does simply not match. Suppose those > jar artifacts are used in an enterprise or web app. Then every artifact is > located in one single directory and therefore the names have to be unique. > But if you decide to take an artifact name different to the directory name, > you have to add the definition in every POM, because the scm elements are > simply wrong. > An even worse scenario are components that can be provided using different > technologies. We have a lot of such structures: > * component > ** jar > ** war > ** ear > * *_jar_:* the core functionality > * *_war_:* the core functionality integrated and eccessible with a web > application > * *_ear_:* the complete component as enterprise app, if it makes sense to > deploy the functionality on a different app server > _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs > with the according package type. All of the three POMs use the same > artifactId though. In this case not only the scm elements break, but also the > URLs for the site, since they are all the same for all three artifacts. > All of this could have been avoided, if the expanded part is not the > artifactId, but the basename of the current directory. Especially for the scm > elements, this is IMHO the only valid assumption. > It would already help us, if this auto-expansion could be turned off to allow > the definition of a single property in each POM for a correct interpolation > of those values, but there seems no such option ^1^. So you *have to* add > those elements under all circumstances into every POM. > 1) The _tagBase_ of the release plugin does no such auto-expansion, which > makes it quite easy to use a property for it, that can be set individually in > every POM without adding any plugin configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2290) Generated URLs in POMs of child modules
[ http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92415 ] William Ferguson edited comment on MNG-2290 at 8/1/07 6:35 PM: --- It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http:///svn/ /trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. was: It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http:///svn//trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. > Generated URLs in POMs of child modules > --- > > Key: MNG-2290 > URL: http://jira.codehaus.org/browse/MNG-2290 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 >Reporter: Joerg Schaible > Fix For: 2.0.x > > > Maven has quite some elements where a URL or a path is modified automatically > for child POMs (the ones I am currently aware of): > - url > - scm/connection > - scm/developerConnection > - scm/url > - distributionManagement/site/url > While expanding this path with "/${pom.artifactId}" sounds reasonable, this > approach fails badly for complex projects with more hierarchy levels. Suppose > we have a directory structure like: > * project > ** core > *** provider > commons > impl1 > In this hierarchy all POMs for _project_, _core_ and _provider_ are of > package type _pom_, while _commons_ and _impl1_ is of type _jar_. The > "artifactId" approach now simply assumes that all POMs in the hierarchy are > named like the current directory. This does simply not match. Suppose those > jar artifacts are used in an enterprise or web app. Then every artifact is > located in one single directory and therefore the names have to be unique. > But if you decide to take an artifact name different to the directory name, > you have to add the definition in every POM, because the scm elements are > simply wrong. > An even worse scenario are components that can be provided using different > technologies. We have a lot of such structures: > * component > ** jar > ** war > ** ear > * *_jar_:* the core functionality > * *_war_:* the core functionality integrated and eccessible with a web > application > * *_ear_:* the complete component as enterprise app, if it makes sense to > deploy the functionality on a different app server > _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs > with the according package type. All of the three POMs use the same > artifactId though. In this case not only the scm elements break, but also the > URLs for the site, since they are all the same for all three artifacts. > All of this could have been avoided, if the expanded part is not the > artifactId, but the basename of the current directory. Especially for the scm > elements, this is IMHO the only valid assumption. > It would already help us, if this auto-expansion could be turned off to allow > the definition of a single property in each POM for a correct interpolation > of those values, but there seems no such option ^1^. So you *have to* add > those elements under all circumstances into every POM. > 1) The _tagBase_ of the release plugin does no such auto-expansion, which > makes it quite easy to use a property for it, that can be set individually in > every POM without adding any plugin configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103820
]
William Ferguson edited comment on MNG-2290 at 8/1/07 6:34 PM:
---
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imagine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eg
http://myhost/maven-projects/${artifactId}/${version}
or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
was:
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imgaine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eh
http://myhost/maven-projects/${artifactId}/${version} or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId t
[jira] Commented: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103820
]
William Ferguson commented on MNG-2290:
---
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imgaine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eh
http://myhost/maven-projects/${artifactId}/${version} or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (MENFORCER-14) Enforcer Plugin Messes Up Dependencies
[
http://jira.codehaus.org/browse/MENFORCER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-14.
--
Resolution: Duplicate
This is a duplicate of MENFORCER-11. The fix is easy, change enforce-once to
enforce.
Also, I noticed in one of your poms that you use ${project.version} This can
cause subtle problems and you are better off defining a property in a parent
and using that (because the property won't change until you change it by hand)
The issue is here:MNG-2486
> Enforcer Plugin Messes Up Dependencies
> --
>
> Key: MENFORCER-14
> URL: http://jira.codehaus.org/browse/MENFORCER-14
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
>Reporter: James Carman
>Assignee: Brian Fox
> Attachments: toplevel.zip
>
>
> When using the enforcer plugin, it somehow messes up the dependencies in a
> reactor-based build. The attached zip file exhibits the problem. Our project
> structure is a bit weird. We have one top-level project which contains a
> bunch of modules. One of the modules is a pom-based "tempalte" project which
> sets up all of our build settings (src/target for the compiler, turns on the
> aspectj compiler, etc.). All of the other modules extend the "template"
> project and they themselves have multiple sub-project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1356) intermittent (machine wise) test failure on trunk
[ http://jira.codehaus.org/browse/CONTINUUM-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell closed CONTINUUM-1356. -- Assignee: Jesse McConnell Resolution: Fixed Fix Version/s: 1.1-beta-2 svn commit: r561907 there was a 1.1-SNAPSHOT parent reference in a test pom...and when we left the 1.1-SNAPSHOT version it started failing if you didn't have that 1.1-SNAPSHOT continuum parent version in your local repo changed it to 1.0.3 so this shouldn't happen again...all the others were fine, looks like this one was missed sometime in the past > intermittent (machine wise) test failure on trunk > - > > Key: CONTINUUM-1356 > URL: http://jira.codehaus.org/browse/CONTINUUM-1356 > Project: Continuum > Issue Type: Bug > Components: Core - Profiles >Affects Versions: 1.1-beta-1 >Reporter: Jesse McConnell >Assignee: Jesse McConnell > Fix For: 1.1-beta-2 > > > I have been noticing an odd test case that has been failing on certain > machines but have been unable to reproduce it locally on my dev box. > Working on a fresh installation on a friends machine I was able to find and > maybe isolate the error with some more output. > Maybe the profile work lately has caused this to happen but some of us have > something installed in our local repo's that suppress the problem. It looks > to me that the creation of a project with a bogus module definition is adding > an additional error to the building results on these machines and with this > output we can see that its not the /test-classes/projects/continuum/pom.xml > artifact causing the problem but the I'm-not-here-project one. > I am making this issue so we have a bit of a record on it and maybe we can > track down why this doesn't manifest on installations such as mine (and I > think emm as well) > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-core/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-model/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-plexus-application/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-web/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-xmlrpc/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/continuum-notifiers/pom.xml > [INFO] Downloading > file:/home/jjchapman/src/trunks/continuum/continuum-core/targ > et/test-classes/projects/continuum/I'm-not-here-project/pom.xml > add.project.artifact.not.found.error > add.project.missing.pom.error > [ stderr ] --- > [ stacktrace ] --- > junit.framework.AssertionFailedError: expected:<1> but was:<2> > at junit.framework.Assert.fail(Assert.java:47) > at junit.framework.Assert.failNotEquals(Assert.java:282) > at junit.framework.Assert.assertEquals(Assert.java:64) > at junit.framework.Assert.assertEquals(Assert.java:201) > at junit.framework.Assert.assertEquals(Assert.java:207) > at > org.apache.maven.continuum.project.builder.maven.MavenTwoContinuumPro > jectBuilderTest.testCreateProjectsWithModules(MavenTwoContinuumProjectBuilderTes > t.java:200) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.i
[jira] Issue Comment Edited: (MNG-3128) Enforcer Plugin Messes Up Dependencies
[ http://jira.codehaus.org/browse/MNG-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103802 ] James Carman edited comment on MNG-3128 at 8/1/07 1:18 PM: --- I am moving this to the Maven Enforcer Plugin project... was: I opened this up in the correct place. > Enforcer Plugin Messes Up Dependencies > -- > > Key: MNG-3128 > URL: http://jira.codehaus.org/browse/MNG-3128 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: James Carman > Attachments: toplevel.zip > > > When using the enforcer plugin, it somehow messes up the dependencies in a > reactor-based build. The attached zip file exhibits the problem. Our > project structure is a bit weird. We have one top-level project which > contains a bunch of modules. One of the modules is a pom-based "tempalte" > project which sets up all of our build settings (src/target for the compiler, > turns on the aspectj compiler, etc.). All of the other modules extend the > "template" project and they themselves have multiple sub-project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3128) Enforcer Plugin Messes Up Dependencies
[ http://jira.codehaus.org/browse/MNG-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman closed MNG-3128. - Resolution: Incomplete > Enforcer Plugin Messes Up Dependencies > -- > > Key: MNG-3128 > URL: http://jira.codehaus.org/browse/MNG-3128 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: James Carman > Attachments: toplevel.zip > > > When using the enforcer plugin, it somehow messes up the dependencies in a > reactor-based build. The attached zip file exhibits the problem. Our > project structure is a bit weird. We have one top-level project which > contains a bunch of modules. One of the modules is a pom-based "tempalte" > project which sets up all of our build settings (src/target for the compiler, > turns on the aspectj compiler, etc.). All of the other modules extend the > "template" project and they themselves have multiple sub-project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-14) Enforcer Plugin Messes Up Dependencies
Enforcer Plugin Messes Up Dependencies -- Key: MENFORCER-14 URL: http://jira.codehaus.org/browse/MENFORCER-14 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Reporter: James Carman Assignee: Brian Fox Attachments: toplevel.zip When using the enforcer plugin, it somehow messes up the dependencies in a reactor-based build. The attached zip file exhibits the problem. Our project structure is a bit weird. We have one top-level project which contains a bunch of modules. One of the modules is a pom-based "tempalte" project which sets up all of our build settings (src/target for the compiler, turns on the aspectj compiler, etc.). All of the other modules extend the "template" project and they themselves have multiple sub-project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-35) Generated documentation for @phase is misleading
Generated documentation for @phase is misleading Key: MPLUGIN-35 URL: http://jira.codehaus.org/browse/MPLUGIN-35 Project: Maven 2.x Plugin Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Matthew Beermann Priority: Minor Fix For: 2.4 If you have the @phase annotation in your mojo, the generated documentation will look something like: "Automatically executes within the lifecycle phase: validate " This is misleading; the goal will _not_ automatically execute - very few goals in Maven do. Instead, you need an section in your POM. I think it would be clearer to just say "Executes during the lifecycle phase: validate" or something like that. -- 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103791 ] Basil James Whitehouse III commented on MNG-3043: - This also seems to affect the Release plugin when performing a release:prepare. > Allow 'mvn test' to work with test-jar dependencies in a reactor > > > Key: MNG-3043 > URL: http://jira.codehaus.org/browse/MNG-3043 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Reactor and workspace >Affects Versions: 2.0.6, 2.0.7, 2.1 >Reporter: Kenney Westerhof > Fix For: Reviewed Pending Version Assignment > > > Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn > install', you run 'mvn test'. > Test classes of dependencies should be resolved from the reactor, just as > main classes, if there's no archive available. > I'm not sure how to go about this. Specifying a dependency on something with > test-jar, > and having that dependency declare the maven-jar-plugin with the 'test-jar' > goal is insufficient. > Perhaps we can just add a standard classifier that maven is aware of, in this > case 'tests'. The jar packaging > would export this as a known classifier, and tells maven how it contributes > to what classpath. > Since test sources are a first class citizen, just as main sources are (they > have the same phases, same > elements in the pom (but differently named)). > It seems logical to me that somehow the test classes should be made available > to dependencies, > if they declare a dependency with classifier 'tests'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPA-91) Come up with a minimal workflow for JIRA
[ http://jira.codehaus.org/browse/MPA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-91. --- Resolution: Fixed > Come up with a minimal workflow for JIRA > > > Key: MPA-91 > URL: http://jira.codehaus.org/browse/MPA-91 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: Maven 2.1 Prep > > > At least: > - shows issues that have not been looked at by anyone or categorized. > Once we initially do a cleanup we should be able to manage this on a daily > basis -- 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: (MJAVADOC-141) regression: Adding "jar" execution to the parent of a multi-module javadoc plugin causes "recursive invocations" error
regression: Adding "jar" execution to the parent of a multi-module javadoc plugin causes "recursive invocations" error -- Key: MJAVADOC-141 URL: http://jira.codehaus.org/browse/MJAVADOC-141 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Mike Youngstrom I have a multimodule project with the javadoc plugin declared in my parent. org.apache.maven.plugins maven-javadoc-plugin 2.3 true attach-javadocs jar After upgrading to 2.3 and do a build I now get the error: [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping Which then skips the processing of that module and later gives me dependency errors because previous dependencies were not compiled. If I remove jar processing from my plugin definition everything works fine except no javadoc jars are created. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCOMPILER-10) display summary information including number of compiler errors when compiler plugin fails.
[ http://jira.codehaus.org/browse/MCOMPILER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] yair567 updated MCOMPILER-10: - Attachment: logExample.bmp HI evry one I tried to send mail to the mailing list but i got an eror so here is my question I new to maven I try integration between eclipse and maven with my little project example but I got a Compilation error The problem is that it not tell me what is the problem These is what I got [INFO] [INFO] Building Unnamed - logging:logging:jar:0.0.1 [INFO]task-segment: [package] [INFO] [INFO] resources:resources [INFO] Using default encoding to copy filtered resources. [INFO] compiler:compile [INFO] Compiling 3 source files to D:\ladpc\workspaces\ladpcApp\logging\target\classes [ERROR] mojo-execute : compiler:compile Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project [ERROR] project-execute : logging:logging:jar:0.0.1 ( task-segment: [package] ) Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) 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.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 8 more But what is the problem? Here is my project tree Thank you all Yair > display summary information including number of compiler errors when compiler > plugin fails. > --- > > Key: MCOMPILER-10 > URL: http://jira.codehaus.org/browse/MCOMPILER-10 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: John Casey >Priority: Minor > Attachments: logExample.bmp > > -- 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-123) Create an xdoc DTD or XSD for maven 2
[ http://jira.codehaus.org/browse/DOXIA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103772 ] Vincent Siveton commented on DOXIA-123: --- I created a branch for this issue: https://svn.apache.org/repos/asf/maven/doxia/doxia/branches/doxia-modules/doxia-module-xdoc/DOXIA-123 > Create an xdoc DTD or XSD for maven 2 > - > > Key: DOXIA-123 > URL: http://jira.codehaus.org/browse/DOXIA-123 > Project: Maven Doxia > Issue Type: Task > Components: Module - Xdoc >Reporter: Lukas Theussl > Fix For: 1.0-beta-1 > > > In Maven 1, a valid xdoc was defined to be something that was converted into > a valid xhtml document by the m1 xdoc plugin. I guess in m2 the same > procedure should be applied to doxia. We need to identify the features that > 1) should be added 2) should be removed with respect to the m1 xdoc dtd. -- 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-373) Unable to delete the pre-configured example network proxy
[ http://jira.codehaus.org/browse/MRM-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD closed MRM-373. -- Resolution: Fixed This issue is no longer valid. I close it. > Unable to delete the pre-configured example network proxy > - > > Key: MRM-373 > URL: http://jira.codehaus.org/browse/MRM-373 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Fabrice BELLINGARD >Priority: Critical > Fix For: 1.0-beta-1 > > > Archiva comes pre-configured with a network proxy. > When I delete it in the web UI, it comes back the next time I start Archiva. > It does not get removed from ~/.m2/archiva.xml. > Workaround: stop Archiva and edit ~/.m2/archiva.xml, then restart -- 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-1659) rhino-js-1.6R6
rhino-js-1.6R6 -- Key: MAVENUPLOAD-1659 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1659 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot Downloaded from http://developer.mozilla.org/en/docs/Rhino_downloads New features in 1.6R6 can be found at http://developer.mozilla.org/en/docs/New_in_Rhino_1.6R6 -- 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-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103763 ] Maria Odea Ching commented on MRM-329: -- Thanks for the patch Teody.. the reports definitely looks better now :) I agree with Brett's comments, especially the constraints/fields being grouped together in one form. It'll be easier for the user to use. Below are some additional comments: - Can the version link in the reports be removed? I think it would always display the 'Unable to find...' error message whenever you click it since the project model is never added to the database once it is found to be invalid - Could you provide some unit tests for these? - And lastly, what about the reports not being accessible to only those users with admin roles? Should that be included here? Or is that a separate issue? Btw, I didn't see the tanuki WrapperSimpleApp started when I executed the reports :) > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-database-20070801.patch, > MRM-329-archiva-model-20070727.patch, MRM-329-archiva-model-20070801.patch, > MRM-329-archiva-webapp-20070725.patch, MRM-329-archiva-webapp-20070801.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- 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-3129) Failed to copy full contents from
Failed to copy full contents from
-
Key: MNG-3129
URL: http://jira.codehaus.org/browse/MNG-3129
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.7
Reporter: Thomas Hart
Priority: Blocker
Attachments: error.log
Every time i execute a maven i get the message: 'Failed to copy full contents'.
I check the code from the class FileUtils and there is a simle File#length()
compare.
{code}
if( source.length() != destination.length() )
{
final String message = "Failed to copy full contents from " + source +
" to " + destination;
throw new IOException( message );
}
{code}
mvn -version
Maven version: 2.0.7
Java version: 1.5.0_04
OS name: "windows xp" version: "5.1" arch: "x86"
--
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: (MPJAR-56) Per package package name invalid in manifest
Per package package name invalid in manifest Key: MPJAR-56 URL: http://jira.codehaus.org/browse/MPJAR-56 Project: Maven 1.x Jar Plugin Issue Type: Bug Affects Versions: 1.8.1 Environment: Windows XP, Maven 1.1 release, JDK 1.4, 1.5 and 1.6 Reporter: Josselin Pujo Priority: Minor Package versionning has been moved from the Jar level to the package level in Maven 1.1, wich is better for jar merging tools. But the package name generated by maven is generated by the following rule: wich does not add the final / to the package name. Replacing With Solves the problem. Best regards, Josselin Pujo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1358) Adding in page in Administration to execute sql queries
Adding in page in Administration to execute sql queries --- Key: CONTINUUM-1358 URL: http://jira.codehaus.org/browse/CONTINUUM-1358 Project: Continuum Issue Type: New Feature Components: Web interface Affects Versions: 1.1-beta-1 Reporter: Olivier Lamy In order to can easily execute sql queries on the database, it could be nice to have a page (only available for administrators) with a text box which can contains sql queries to execute. NOTE : it can be dangerous because queries can break model integrity. Thoughts ? -- 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] Created: (MRELEASE-272) Release plugin tags into wrong directory
Release plugin tags into wrong directory Key: MRELEASE-272 URL: http://jira.codehaus.org/browse/MRELEASE-272 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-6, 2.0-beta-4 Environment: osx 10.4, java 5 Reporter: David Jencks I tried to use the release plugin, both beta-6 and beta-4 to release some new geronimo jars, but it kept tagging into a parent poms directory, not the one specified in the scm element OR one specified on the command line via -DtagBase. To see this svn co -r561686 https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk mvn release:prepare -DdryRun=true -DtagBase=https://svn.apache.org/repos/asf/geronimo/components/txmanager cat pom.xml.tag The parent pom does not have a scm section. Would that help? As I write it is not yet released, for simplicity you may want to check it out from svn co https://svn.apache.org/repos/asf/geronimo/genesis/branches/1.2 the release plugin version specified there is 2.0-beta-4 but changing it to beta-6 has no apparent effect. -- 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-1353) after a few weeks, continuum runs into outofmemory error
[ http://jira.codehaus.org/browse/CONTINUUM-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103750 ] tony nys commented on CONTINUUM-1353: - deleting records from these tables fixes the problem temporarily... BUILDRESULT BUILDRESULT_MODIFIEDDEPENDENCIES CHANGEFILE CHANGESET > after a few weeks, continuum runs into outofmemory error > > > Key: CONTINUUM-1353 > URL: http://jira.codehaus.org/browse/CONTINUUM-1353 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1-alpha-2 >Reporter: tony nys >Priority: Blocker > > when clicking on the build history, memory of the jvm increases from 100MB > until 470MB > after that it crashes with outofmemory error (JDO exception) > Increasing the plexus jvm memory does have no affect: > %PLEXUS_JAVA_EXE% %PLEXUS_OPTS% -Xmx900M -XX:MaxPermSize=128m -classpath > "%PLEXUS_HOME%\core\boot\plexus-classworlds-1.2-alpha-7.jar" > -Dclassworlds.conf="%PLEXUS_HOME%\conf\classworlds.conf" > -Dplexus.core=%PLEXUS_CORE% -Dplexus.system.path="%PATH%" > -Djava.io.tmpdir=%PLEXUS_TMPDIR% -Dplexus.home="%PLEXUS_HOME%" > -Dappserver.base="%PLEXUS_BASE%" -Dtools.jar="%TOOLS_JAR%" > org.codehaus.plexus.classworlds.launcher.Launcher %PLEXUS_CMD_LINE_ARGS% > So probably bug in fetch from db where all objects are retrieved ? > For us this is a showstopper. Would MySQL DB be a workaround ? I guess the > query is the same, so will the memory usage be ? > Where can I find the complete DDL script for mysql ? On the wiki there is > only 1 table ... ? > javax.jdo.JDODataStoreException: Iteration request failed : > SELECT > THIS.CHANGEFILE_ID,THIS.MODEL_ENCODING,THIS."NAME",THIS.REVISION,THIS.STATUS,THIS.FILES_INTEGER_IDX > AS JPOXORDER0 FROM > CHANGEFILE THIS WHERE ? = THIS.FILES_CHANGESET_ID_OID AND > THIS.FILES_INTEGER_IDX >= ? ORDER BY JPOXORDER0 NestedThrowables: SQL > Exception: Java exception: > 'Java heap space: java.lang.OutOfMemoryError'. -- 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-1355) No admin user found after Tomcat shutdown
[ http://jira.codehaus.org/browse/CONTINUUM-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103749 ] Pavel Halas commented on CONTINUUM-1355: You can take a look at the config file -- Derby is used as a data source. I admit it might be purely Tomcat or Derby issue -- this happens when Tomcat needs to be killed (kill -9) and the database hence is not parked properly -- that's my guess. So the question might be "Why tomcat needs to be killed?" or "Why Derby is not able to recover after shut down?"... I'm waiting for anyone else dealing with the same to provide some additional remarks. Thanks. > No admin user found after Tomcat shutdown > - > > Key: CONTINUUM-1355 > URL: http://jira.codehaus.org/browse/CONTINUUM-1355 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux, Tomcat 5.5.17 >Reporter: Pavel Halas >Priority: Critical > Attachments: continuum.xml > > > Hi, > using the latest snapshot (from yesterday) running on Tomcat 5.5.17. After > the Tomcat kill and running again, Continuum starts with "Create Admin User" > page saying "No admin user found" in the log. > This has been experienced even with the older versions (1.1 snapshots). -- 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-1355) No admin user found after Tomcat shutdown
[ http://jira.codehaus.org/browse/CONTINUUM-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Halas updated CONTINUUM-1355: --- Attachment: continuum.xml Tomcat context definition file. > No admin user found after Tomcat shutdown > - > > Key: CONTINUUM-1355 > URL: http://jira.codehaus.org/browse/CONTINUUM-1355 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 > Environment: Linux, Tomcat 5.5.17 >Reporter: Pavel Halas >Priority: Critical > Attachments: continuum.xml > > > Hi, > using the latest snapshot (from yesterday) running on Tomcat 5.5.17. After > the Tomcat kill and running again, Continuum starts with "Create Admin User" > page saying "No admin user found" in the log. > This has been experienced even with the older versions (1.1 snapshots). -- 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
