[jira] Moved: (SUREFIRE-304) Out of memory with mvn test
[ http://jira.codehaus.org/browse/SUREFIRE-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MPTEST-72 to SUREFIRE-304: - Complexity: Intermediate Workflow: Maven New (was: jira) Key: SUREFIRE-304 (was: MPTEST-72) Project: Maven Surefire (was: maven-test-plugin) > Out of memory with mvn test > --- > > Key: SUREFIRE-304 > URL: http://jira.codehaus.org/browse/SUREFIRE-304 > Project: Maven Surefire > Issue Type: Bug > Environment: WINDOWS 2000, JDK1.5, JUNIT >Reporter: Punit Mishra >Priority: Critical > > I am getting an out of memory while running my Junits from mvn test. The > MAVEN_OPTS has been specified to 512m which is more than what is needed to > run my tests. > When I print available memory to my tests it shows 1M to 63M only. > Is there any other place where it picks the memory args from. > I could see there are some junit properties that can be set but I am not sure > where and how should I be setting those properties. I tried setting them in > POM.xml but they are not being pickedup. > The same tests are successfully running from within eclipse with same memory > args as specified in MAVEN_OPTS. -- 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-288) Error on startup: NPE, configuration can not be null
[ http://jira.codehaus.org/browse/MRM-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89142 ] Brett Porter commented on MRM-288: -- I thought I had fixed this the other day by adding the default file. It's the ones that are 'config-forceCreate="true"' that need it (note that upgrading to commons-configuration 1.4-SNAPSHOT would also resolve the problem) > Error on startup: NPE, configuration can not be null > > > Key: MRM-288 > URL: http://jira.codehaus.org/browse/MRM-288 > Project: Archiva > Issue Type: Bug > Environment: r510897 >Reporter: Lester Ecarma > > 2007-02-23 18:11:34.480::WARN: Failed startup of context [EMAIL > PROTECTED]/,/home/lecarma/workspace/mergere/OSS/apache/archiva/trunk/archiva-webapp/src/main/webapp} > java.lang.NullPointerException: configuration can not be null > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.(CommonsConfigurationRegistry.java:89) > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.getSection(CommonsConfigurationRegistry.java:422) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.addChangeListener(DefaultArchivaConfiguration.java:86) > at > org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.start(DefaultRepositoryTaskScheduler.java:91) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:143) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:87) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:101) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:313) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) > at > org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:54) > at > org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:928) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:876) > at > org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:853) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:222) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:236) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:76) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginWebApplication.start(Jetty6PluginWebApplication.java:147) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.changesDetected(AbstractJettyRunMojo.java:372) > at org.mortbay.jetty.plugin.util.Scanner.run(Scanner.java:159) > This causes a 404 -- 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: (MPTEST-72) Out of memory with mvn test
Out of memory with mvn test --- Key: MPTEST-72 URL: http://jira.codehaus.org/browse/MPTEST-72 Project: maven-test-plugin Issue Type: Bug Environment: WINDOWS 2000, JDK1.5, JUNIT Reporter: Punit Mishra Priority: Critical I am getting an out of memory while running my Junits from mvn test. The MAVEN_OPTS has been specified to 512m which is more than what is needed to run my tests. When I print available memory to my tests it shows 1M to 63M only. Is there any other place where it picks the memory args from. I could see there are some junit properties that can be set but I am not sure where and how should I be setting those properties. I tried setting them in POM.xml but they are not being pickedup. The same tests are successfully running from within eclipse with same memory args as specified in MAVEN_OPTS. -- 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: (ARCHETYPE-65) Restore the ability to "package" non-Java resources
Restore the ability to "package" non-Java resources --- Key: ARCHETYPE-65 URL: http://jira.codehaus.org/browse/ARCHETYPE-65 Project: Maven Archetype Issue Type: Bug Components: Creator Affects Versions: 1.0-alpha-4 Reporter: Wendy Smoak Attachments: archetype-resource-package-interpolation.patch Some time ago, the Archetype plugin lost the ability to "package" non-Java resources. The change was committed in April '06, so it would have first appeared in 1.0-alpha-4. http://mail-archives.apache.org/mod_mbox/maven-commits/200604.mbox/[EMAIL PROTECTED] Prior to this change, you could put non-Java files in the element, for example src/main/resources/App.properties and mvn archetype:create ... -DgroupId=com.example would result in src/main/resources/com/example/App.properties Now, you get an error saying: "Template 'App.properties' is not in directory src/main/java." One way to fix this is to roll back the changes from lines 682-705 in r390971: http://svn.apache.org/viewvc/maven/archetype/trunk/maven-archetype/maven-archetype-core/src/main/java/org/apache/maven/archetype/DefaultArchetype.java?r1=390965&r2=390971&diff_format=h However if I'm reading the changes right, that will break the ability to have "sub packages". Maybe we need to leave alone, and have both and ? There is an example project (based on the quickstart archetype) in the sandbox. It includes App.properties as described above. http://svn.apache.org/repos/asf/maven/sandbox/trunk/archetype/maven-archetype-quickstart/ -- 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-1200) Password Characters Not Supported in SCM Checkout
[ http://jira.codehaus.org/browse/CONTINUUM-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89131 ] Stephen Duncan Jr commented on CONTINUUM-1200: -- In the scenario being used, no password info is in the scm url. The password was provided when authenticating to download the POM from subversion. > Password Characters Not Supported in SCM Checkout > - > > Key: CONTINUUM-1200 > URL: http://jira.codehaus.org/browse/CONTINUUM-1200 > Project: Continuum > Issue Type: Bug >Reporter: Stephen Duncan Jr > > Certain characters are not supported for the password for an SCM checkout. > For instance if a ')' is the first character, then the command fails. This > is because the password is provided as a CLI parameter, and is not surrounded > by quotes. Obviously, adding quotes might break other passwords, so it would > be best to pass the password along some other way. -- 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-1200) Password Characters Not Supported in SCM Checkout
[ http://jira.codehaus.org/browse/CONTINUUM-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89130 ] Dan Tran commented on CONTINUUM-1200: - did you try to configure your scm url using | separator ? http://maven.apache.org/scm/scm-url-format.html > Password Characters Not Supported in SCM Checkout > - > > Key: CONTINUUM-1200 > URL: http://jira.codehaus.org/browse/CONTINUUM-1200 > Project: Continuum > Issue Type: Bug >Reporter: Stephen Duncan Jr > > Certain characters are not supported for the password for an SCM checkout. > For instance if a ')' is the first character, then the command fails. This > is because the password is provided as a CLI parameter, and is not surrounded > by quotes. Obviously, adding quotes might break other passwords, so it would > be best to pass the password along some other way. -- 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: (ARCHETYPE-62) Allow package.html files to be included in an archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated ARCHETYPE-62: - Summary: Allow package.html files to be included in an archetype (was: Allow Non-Java Resources in sources/testSources to be included in an archetype) Changing the summary to be more specific, since only package.html is a problem. Other non-Java resources (such as overview.html) do get included in the archetype jar. > Allow package.html files to be included in an archetype > --- > > Key: ARCHETYPE-62 > URL: http://jira.codehaus.org/browse/ARCHETYPE-62 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 1.0-alpha-4 >Reporter: Martin Ahrer > > A Java source folder may contain non Java resources such as JavaDoc > package.html etc. > > src/main/java/App.java > src/main/java/package.html > > > src/test/java/AppTest.java > src/main/java/package.html > > Currently when specifying non Java resources they don't get distributed in > the packaged archetype jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-62) Allow Non-Java Resources in sources/testSources to be included in an archetype
[
http://jira.codehaus.org/browse/ARCHETYPE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89127
]
Wendy Smoak commented on ARCHETYPE-62:
--
The package.html file is being excluded by maven-jar-plugin.
http://maven.apache.org/plugins/maven-jar-plugin/xref/org/apache/maven/plugin/jar/AbstractJarMojo.html
39 private static final String[] DEFAULT_EXCLUDES = new
String[]{"**/package.html"};
...
152 archiver.getArchiver().addDirectory( contentDirectory, DEFAULT_INCLUDES,
DEFAULT_EXCLUDES );
It does not appear to be configurable.
> Allow Non-Java Resources in sources/testSources to be included in an archetype
> --
>
> Key: ARCHETYPE-62
> URL: http://jira.codehaus.org/browse/ARCHETYPE-62
> Project: Maven Archetype
> Issue Type: Improvement
>Affects Versions: 1.0-alpha-4
>Reporter: Martin Ahrer
>
> A Java source folder may contain non Java resources such as JavaDoc
> package.html etc.
>
> src/main/java/App.java
> src/main/java/package.html
>
>
> src/test/java/AppTest.java
> src/main/java/package.html
>
> Currently when specifying non Java resources they don't get distributed in
> the packaged archetype jar.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89104 ] Dennis Lundberg commented on MIDEA-39: -- This is working for me using the latest 2.1-SNAPSHOT version of this plugin and IDEA 5.1.2. Can you please try it. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Attachments: module-dependencies.patch > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea 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] Commented: (MCHECKSTYLE-54) checkstyle:check does not see provided scope dependencies
[ http://jira.codehaus.org/browse/MCHECKSTYLE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89102 ] Dennis Lundberg commented on MCHECKSTYLE-54: Do you have includeTestSourceDirectory set to true in your plugin configuration? > checkstyle:check does not see provided scope dependencies > - > > Key: MCHECKSTYLE-54 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-54 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Stephen Duncan Jr >Priority: Critical > > Running checkstyle:check against a project that uses Exceptions from > dependencies that are provided scope causes checktyle errors such as the > following: > name="/share/duncans/workspace/eclipse/cdcie-webapp-feedreader/src/main/java/mil/jfcom/cie/portal/feedreader/converter/ConverterImpl.java"> > > These errors go away when the scope is changed to compile. This does not > happen for checkstyle:checkstyle; the report correct indicates no checkstyle > errors. This is preventing us from using the checkstyle plugin to enforce > checkstyle rules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-66) How to configure maven-checkstyle-plugin with external ImportControl file in your checkstyle configuration ?
[ http://jira.codehaus.org/browse/MCHECKSTYLE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89100 ] Dennis Lundberg commented on MCHECKSTYLE-66: Are you sure that you can use a URL for the file property? The Checkstyle docs doesn't mention this: http://checkstyle.sourceforge.net/config_imports.html#ImportControl Please verify that this works without using Maven. > How to configure maven-checkstyle-plugin with external ImportControl file in > your checkstyle configuration ? > > > Key: MCHECKSTYLE-66 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-66 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Maven 2.0.4 > Windows 200 Pro (command line), Linux Mandrake Server 3.0 (Continuum 1.0.3) >Reporter: Cyril MOREAU >Priority: Blocker > > How to configure maven-checkstyle-plugin with external ImportControl file > in your checkstyle configuration ? > My checstyles configuration is available in > "http://www.xxx.com/repository/rdc";. This > address contains this files : > my_checstyleconfiguration.xml > import-control.xml > In the "my_checstyleconfiguration.xml", the importcontrol is define : > > value="Utilisation d'un package non autoris??"/> > > value="http://www.xxx.com/repository/rdc/import-control.xml"/> > > But when I run maven, build failure because maven doesn't localize > import-control.xml : "http://www.xxx.com/repository/rdc/import-control.xml > (syntaxe de nom de fichier, de répertoire ou de volume incorrect) -- 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-1403) Upload Checkstyle 4.3
Upload Checkstyle 4.3 - Key: MAVENUPLOAD-1403 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1403 Project: maven-upload-requests Issue Type: Task Reporter: Dennis Lundberg http://people.apache.org/~dennisl/bundle/checkstyle-4.3-bundle.jar http://people.apache.org/~dennisl/bundle/checkstyle-optional-4.3-bundle.jar http://checkstyle.sourceforge.net/ The bundle jars have been built from the binaries available for download from Sourceforge, using Ant 1.6.5 and JDK 1.5.0_11. -- 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-2301) Maven Archiver deleteing already existing pom.properties file.
[ http://jira.codehaus.org/browse/MNG-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89094 ] Jochen Wiedmann commented on MNG-2301: -- Please note MNG-2854 (I have created a new bug report, because my issue is the failing uptodate check, which isn't necessarily the same problem than here. Additionally, the suggested solutions are quite different. Nevertheless, it should be possible to close either MNG-2854 (this issue) or MNG-2301 as a duplicate of the other. > Maven Archiver deleteing already existing pom.properties file. > -- > > Key: MNG-2301 > URL: http://jira.codehaus.org/browse/MNG-2301 > Project: Maven 2 > Issue Type: Bug > Components: maven-archiver >Affects Versions: 2.0.4 >Reporter: Sharmarke Aden > Fix For: 2.0.x > > Attachments: maven-archiver_pomDelete.patch > > > My project has it's own pom.properties file and it seems that maven archiver > is deleting it right after packaging the application. Any particular reason > why it's doing this? It seems to me the archiver shouldn't be deleting the > file if it already exists. It should delete the file if it doesn't exists > otherwise it should add the necessary information (version, groupId, etc) to > the file and leave it be. I have attached a patch that fixes the issue. > Also note that this patch adds the "builtOn" property to the pom.properties > which is satisfy the following enhancement request: > http://jira.codehaus.org/browse/MNG-1830 -- 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-2854) Recreating pom.properties always breaks the archivers uptodate check
Recreating pom.properties always breaks the archivers uptodate check
Key: MNG-2854
URL: http://jira.codehaus.org/browse/MNG-2854
Project: Maven 2
Issue Type: Bug
Components: maven-archiver
Affects Versions: 2.0.5
Reporter: Jochen Wiedmann
Attachments: maven-archiver-properties.patch
The maven-archiver creates a file called pom.properties on every invocation.
(Unless the flag "addMavenDescriptor" is set to false, which few people do.)
This forced recreation makes the uptodate check fail. In other words, jar files
are always recreated, regardless whether anything was recompiled. Obviously,
this makes the uptodate check of war files etc. fail as well, because the
included jar files are always changed.. This is a major drawback, because it
makes Maven much slower than, for example, Ant-.
The attached patch proposes a solution for the same problem. What the patch
does:
- It is obviously bad, that the generated pom.properties file is in the
projects directory. The
patch moves the file to ${project.build.directory}/maven-archiver, which
seems to me to
be a more sensible solution.
- Second, whether we like it or not, there are projects, which create multiple
artifacts. In other
words, it isn't good to have a single file. The patch renames the
pom.properties file to
${groupId}/$artifactFinalName.properties. Hopefully, this is sufficiently
unique.
- Finally, the patch makes the maven-archiver check, whether the pom.properties
file has
actually changed. (In other words, whether groupId, artifactId, or version
have changed.)
It does so, by writing the file to an internal buffer and comparing the file
on the disk and
the internal buffer (after skipping the line with the timestamp).
In other words, in the usual case, where groupId, artifactId and version
haven't changed, the pom.properties file remains unchanged. In particular, the
jar file doesn't need to be recreated.
--
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: (MRELEASE-197) Release plugin documentation on maven.apache.org has broken link to release:rollback
[ http://jira.codehaus.org/browse/MRELEASE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MRELEASE-197. Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0-beta-5 Fixed in SVN. Site has been uploaded, but it will take a while until it goes live. > Release plugin documentation on maven.apache.org has broken link to > release:rollback > > > Key: MRELEASE-197 > URL: http://jira.codehaus.org/browse/MRELEASE-197 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Harold Shinsato > Assigned To: Dennis Lundberg > Fix For: 2.0-beta-5 > > > The website lists a release:rollback goal with a broken link. > http://maven.apache.org/plugins/maven-release-plugin/ > Notice the link with the text "release:rollback", it links to > http://maven.apache.org/plugins/maven-release-plugin/rollback-mojo.html which > is a non-existant page. This goal is not listed in other pages of the > documentation for this plugin, so I'm assuming it no longer exists or was > deleted. > Notice that this info page doesn't reference the release:rollback. > http://maven.apache.org/plugins/maven-release-plugin/plugin-info.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] Commented: (ARCHETYPE-62) Allow Non-Java Resources in sources/testSources to be included in an archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89083 ] Wendy Smoak commented on ARCHETYPE-62: -- I've copied the quickstart archetype to the Maven sandbox and added package.html, overview.html and App.properties to demonstrate problems with non-Java resources: http://svn.apache.org/repos/asf/maven/sandbox/trunk/archetype/maven-archetype-quickstart/ The readme file there explains the problems I'm having, including the inability to get package.html into the archetype jar. > Allow Non-Java Resources in sources/testSources to be included in an archetype > -- > > Key: ARCHETYPE-62 > URL: http://jira.codehaus.org/browse/ARCHETYPE-62 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 1.0-alpha-4 >Reporter: Martin Ahrer > > A Java source folder may contain non Java resources such as JavaDoc > package.html etc. > > src/main/java/App.java > src/main/java/package.html > > > src/test/java/AppTest.java > src/main/java/package.html > > Currently when specifying non Java resources they don't get distributed in > the packaged archetype jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2788) Anchor tags on POM amd Settings reference pages are broken in Firefox
[ http://jira.codehaus.org/browse/MNG-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Breidenbach reopened MNG-2788: --- This still is not working in my emvironment: Windows XP SP2 with both Firefox 2.0.0.2 IE 7. For example, in the source code for pom.html, the anchor link looks like this: But the anchor tag looks like this: Not the difference in the capitalization, the mixed use of spaces and underscores and the missing question mark in the anchor tag. > Anchor tags on POM amd Settings reference pages are broken in Firefox > - > > Key: MNG-2788 > URL: http://jira.codehaus.org/browse/MNG-2788 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: General >Affects Versions: 2.0.4 > Environment: Firefox 2.0.0.1 on Windows XP SP2. >Reporter: Ryan Breidenbach > Assigned To: Dennis Lundberg >Priority: Trivial > > The TOC anchors at the top of the POM and Settings Reference pages do not > work in Firefox. It appears that all of the anchor links are capitalized > while the anchor labels are all lower case. Also, some of the links contain > spaces while the labels contain underscores. This is causing the links to > fail in Firefox. > http://maven.apache.org/pom.html > http://maven.apache.org/settings.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] Created: (MAVENUPLOAD-1402) eva-properties-0.2.1
eva-properties-0.2.1 Key: MAVENUPLOAD-1402 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1402 Project: maven-upload-requests Issue Type: Task Reporter: Maximilian Antoni Thank you for uploading. -- 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-288) Error on startup: NPE, configuration can not be null
[ http://jira.codehaus.org/browse/MRM-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89076 ] Wendy Smoak commented on MRM-288: - r513991 has the same problem with a NPE - "configuration can not be null" http://www.nabble.com/Archiva-r513991-will-not-start-t3337388.html > Error on startup: NPE, configuration can not be null > > > Key: MRM-288 > URL: http://jira.codehaus.org/browse/MRM-288 > Project: Archiva > Issue Type: Bug > Environment: r510897 >Reporter: Lester Ecarma > > 2007-02-23 18:11:34.480::WARN: Failed startup of context [EMAIL > PROTECTED]/,/home/lecarma/workspace/mergere/OSS/apache/archiva/trunk/archiva-webapp/src/main/webapp} > java.lang.NullPointerException: configuration can not be null > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.(CommonsConfigurationRegistry.java:89) > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.getSection(CommonsConfigurationRegistry.java:422) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.addChangeListener(DefaultArchivaConfiguration.java:86) > at > org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.start(DefaultRepositoryTaskScheduler.java:91) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:143) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:87) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:101) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:313) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) > at > org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:54) > at > org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:928) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:876) > at > org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:853) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:222) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:236) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:76) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginWebApplication.start(Jetty6PluginWebApplication.java:147) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.changesDetected(AbstractJettyRunMojo.java:372) > at org.mortbay.jetty.plugin.util.Scanner.run(Scanner.java:159) > This causes a 404 -- 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-288) Error on startup: NPE, configuration can not be null
[ http://jira.codehaus.org/browse/MRM-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MRM-288: Environment: r510897 Summary: Error on startup: NPE, configuration can not be null (was: Error on startup of current revision (r510897)) > Error on startup: NPE, configuration can not be null > > > Key: MRM-288 > URL: http://jira.codehaus.org/browse/MRM-288 > Project: Archiva > Issue Type: Bug > Environment: r510897 >Reporter: Lester Ecarma > > 2007-02-23 18:11:34.480::WARN: Failed startup of context [EMAIL > PROTECTED]/,/home/lecarma/workspace/mergere/OSS/apache/archiva/trunk/archiva-webapp/src/main/webapp} > java.lang.NullPointerException: configuration can not be null > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.(CommonsConfigurationRegistry.java:89) > at > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry.getSection(CommonsConfigurationRegistry.java:422) > at > org.apache.maven.archiva.configuration.DefaultArchivaConfiguration.addChangeListener(DefaultArchivaConfiguration.java:86) > at > org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.start(DefaultRepositoryTaskScheduler.java:91) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.StartPhase.execute(StartPhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:130) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:143) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:133) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:87) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:101) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:313) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:291) > at > org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:54) > at > org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:928) > at > org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:876) > at > org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:853) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:222) > at > org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:236) > at > org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:76) > at > org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.plugin.Jetty6PluginWebApplication.start(Jetty6PluginWebApplication.java:147) > at > org.mortbay.jetty.plugin.AbstractJettyRunMojo$1.changesDetected(AbstractJettyRunMojo.java:372) > at org.mortbay.jetty.plugin.util.Scanner.run(Scanner.java:159) > This causes a 404 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-169) Document new elements in the assembly descriptor as "Since 2.2"
[ http://jira.codehaus.org/browse/MASSEMBLY-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89074 ] Wendy Smoak commented on MASSEMBLY-169: --- The different version numbers for artifacts vs. models are already a fact of life. For example, Maven 2.0.x uses maven-model 4.0.x. IMO we need a visual marker that something is "different", and then to explain how to interpret the information. I remain convinced that users will adapt to it, and that it's better than the confusion we have now. +1 to go ahead with the changes in modello-maven-plugin and start using this. > Document new elements in the assembly descriptor as "Since 2.2" > --- > > Key: MASSEMBLY-169 > URL: http://jira.codehaus.org/browse/MASSEMBLY-169 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Wendy Smoak >Priority: Blocker > Fix For: 2.2 > > Attachments: assembly-since-2.2.patch > > > The assembly.html page includes elements introduced after the 2.1 release. > These need to be documented as "Since 2.2" to avoid confusion. > (Another option would be for modello:xdoc to generate something based on the > in the model.) -- 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: (MEV-507) Remove ch/qos/logback/logback directory on ibiblio
[ http://jira.codehaus.org/browse/MEV-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ceki Gulcu closed MEV-507. -- Resolution: Duplicate > Remove ch/qos/logback/logback directory on ibiblio > -- > > Key: MEV-507 > URL: http://jira.codehaus.org/browse/MEV-507 > Project: Maven Evangelism > Issue Type: Task >Reporter: Ceki Gulcu > > The "ch/qos/logback/logback/" directory [1] on ibiblio exists due to a > syncronisation error. However, looking at [1], many logback users > errorneously think that the latest logback version on ibiblio is v0.5. Could > please remove the "ch/qos/logback/logback/" directory on the ibiblio repo? > Please note that this directory should have never existed. > Many thanks in advance, > [1] http://mirrors.ibiblio.org/pub/mirrors/maven2/ch/qos/logback/logback/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-507) Remove ch/qos/logback/logback directory on ibiblio
[ http://jira.codehaus.org/browse/MEV-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89073 ] Ceki Gulcu commented on MEV-507: This report should have been filed under "Maven-upload" not "Maven evangelism". I have filed another more appropritate bug report as MAVENUPLOAD-1401. Consequently, I will close this report. > Remove ch/qos/logback/logback directory on ibiblio > -- > > Key: MEV-507 > URL: http://jira.codehaus.org/browse/MEV-507 > Project: Maven Evangelism > Issue Type: Task >Reporter: Ceki Gulcu > > The "ch/qos/logback/logback/" directory [1] on ibiblio exists due to a > syncronisation error. However, looking at [1], many logback users > errorneously think that the latest logback version on ibiblio is v0.5. Could > please remove the "ch/qos/logback/logback/" directory on the ibiblio repo? > Please note that this directory should have never existed. > Many thanks in advance, > [1] http://mirrors.ibiblio.org/pub/mirrors/maven2/ch/qos/logback/logback/ -- 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-1401) Remove ch/qos/logback/logback directory on ibiblio
Remove ch/qos/logback/logback directory on ibiblio -- Key: MAVENUPLOAD-1401 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1401 Project: maven-upload-requests Issue Type: Task Reporter: Ceki Gulcu The "ch/qos/logback/logback/" directory [1] on ibiblio exists due to a syncronisation error. However, looking at [1], logback users errorneously think that the latest logback version on ibiblio is v0.5. Could please remove the "ch/qos/logback/logback/" directory on the ibiblio repo? Please note that this directory should have never existed. Many thanks in advance, [1] http://mirrors.ibiblio.org/pub/mirrors/maven2/ch/qos/logback/logback/ -- 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: (MGPG-1) Prompt for pass phrase if it is not supplied
[ http://jira.codehaus.org/browse/MGPG-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated MGPG-1: --- Affects Version/s: 1.0-alpha-1 Fix Version/s: 1.0-alpha-3 > Prompt for pass phrase if it is not supplied > > > Key: MGPG-1 > URL: http://jira.codehaus.org/browse/MGPG-1 > Project: Maven 2.x GPG Plugin > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak > Assigned To: Daniel Kulp > Fix For: 1.0-alpha-3 > > > The plugin should prompt for a pass phrase if one is not supplied, and should > mask the input. (The pass phrase should not be visible or stored in plain > text.) > Brian Fox suggested the plugin should detect that Maven is running in batch > mode, and not prompt in that case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MGPG-2) Allow the selection of a particular signature
[ http://jira.codehaus.org/browse/MGPG-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated MGPG-2: --- Affects Version/s: (was: 1.0-alpha-2) 1.0-alpha-1 Fix Version/s: 1.0-alpha-3 > Allow the selection of a particular signature > - > > Key: MGPG-2 > URL: http://jira.codehaus.org/browse/MGPG-2 > Project: Maven 2.x GPG Plugin > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Jason van Zyl > Assigned To: Daniel Kulp > Fix For: 1.0-alpha-3 > > > Folks could have many signature and want to use a particular one. -- 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-1200) Password Characters Not Supported in SCM Checkout
Password Characters Not Supported in SCM Checkout - Key: CONTINUUM-1200 URL: http://jira.codehaus.org/browse/CONTINUUM-1200 Project: Continuum Issue Type: Bug Reporter: Stephen Duncan Jr Certain characters are not supported for the password for an SCM checkout. For instance if a ')' is the first character, then the command fails. This is because the password is provided as a CLI parameter, and is not surrounded by quotes. Obviously, adding quotes might break other passwords, so it would be best to pass the password along some other way. -- 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-1199) Password Characters Not Supported in HTTP Authentication
Password Characters Not Supported in HTTP Authentication Key: CONTINUUM-1199 URL: http://jira.codehaus.org/browse/CONTINUUM-1199 Project: Continuum Issue Type: Bug Affects Versions: 1.1 Reporter: Stephen Duncan Jr When entering a url +username + password to download a pom to configure a project, certain password characters will cause it to fail. This is because the password is inserted into the url, so url special characters (@,?, etc) will not work. The password should be provided in response to the challenge, rather than as part of the url. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2810) Create a Windows Installer and update instructions on download site
[ http://jira.codehaus.org/browse/MNG-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89070 ] Dennis Lundberg commented on MNG-2810: -- The download instructions have been fixed. > Create a Windows Installer and update instructions on download site > --- > > Key: MNG-2810 > URL: http://jira.codehaus.org/browse/MNG-2810 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.4 > Environment: http://maven.apache.org/download.html >Reporter: Archimedes Trajano > > Please add a Windows installer (similar to the one that was done in Maven > 1.x) and update the instructions on http://maven.apache.org/download.html > since it still refers to 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] Closed: (MNG-2788) Anchor tags on POM amd Settings reference pages are broken in Firefox
[ http://jira.codehaus.org/browse/MNG-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNG-2788. Assignee: Dennis Lundberg Resolution: Fixed This seems to have been fixed now. > Anchor tags on POM amd Settings reference pages are broken in Firefox > - > > Key: MNG-2788 > URL: http://jira.codehaus.org/browse/MNG-2788 > Project: Maven 2 > Issue Type: Bug > Components: Documentation: General >Affects Versions: 2.0.4 > Environment: Firefox 2.0.0.1 on Windows XP SP2. >Reporter: Ryan Breidenbach > Assigned To: Dennis Lundberg >Priority: Trivial > > The TOC anchors at the top of the POM and Settings Reference pages do not > work in Firefox. It appears that all of the anchor links are capitalized > while the anchor labels are all lower case. Also, some of the links contain > spaces while the labels contain underscores. This is causing the links to > fail in Firefox. > http://maven.apache.org/pom.html > http://maven.apache.org/settings.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: (ARCHETYPE-60) Archetype Documentation Incorrect
[ http://jira.codehaus.org/browse/ARCHETYPE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed ARCHETYPE-60. Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 1.0 Fixed in SVN. > Archetype Documentation Incorrect > - > > Key: ARCHETYPE-60 > URL: http://jira.codehaus.org/browse/ARCHETYPE-60 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 1.0-alpha-4 > Environment: n/a >Reporter: David Whitehurst > Assigned To: Dennis Lundberg > Fix For: 1.0 > > Attachments: guide-creating-archetypes.html > > > The documentation at > http://maven.apache.org/guides/mini/guide-creating-archetypes.html is > incorrect. The specification of resources is incorrect. A fixed html file > is attached. The testSources and siteResources tags are specified > incorrectly with dashes. -- 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: (MAVEN-1834) Java sources in War file not build unless at least 1 unit test is present
[ http://jira.codehaus.org/browse/MAVEN-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89055 ] Lukas Theussl commented on MAVEN-1834: -- What command are you running, ie what are you trying to do? A test project to reproduce the issue would also help. > Java sources in War file not build unless at least 1 unit test is present > - > > Key: MAVEN-1834 > URL: http://jira.codehaus.org/browse/MAVEN-1834 > Project: Maven 1.x > Issue Type: Bug >Affects Versions: 1.1-beta-3 > Environment: Win2000 >Reporter: Axel Fontaine > > Within a multiproject (have not tested standalone), when a war subproject > contains java code and/or resources, but no test cases, the java code does > not get compiled/the resources do not get copied and therefore not packaged. > Works fine in maven 1.0.2 > Workaround: Adding a dummy unit test -- 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: (MCHANGES-71) need add template encoding to announcement-generate
need add template encoding to announcement-generate --- Key: MCHANGES-71 URL: http://jira.codehaus.org/browse/MCHANGES-71 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Yao Yong I need to generate a Chinese announcement, would you please add the following velocity property into parameters input.encoding output.encoding -- 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
