[jira] Updated: (MIDEA-35) Module Libraries and WebModule libraries to package should not have a name attribute
[ http://jira.codehaus.org/browse/MIDEA-35?page=all ] Johann Reyes updated MIDEA-35: -- Attachment: MIDEA-35.patch > Module Libraries and WebModule libraries to package should not have a name > attribute > > > Key: MIDEA-35 > URL: http://jira.codehaus.org/browse/MIDEA-35 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Priority: Blocker > Attachments: MIDEA-35.patch, idea-2.patch > > > Idea 5.x does not seem to support name attributes in module library > definitions. At least it leads to buggy behavior when WebModule settings are > involved. > There is no way to add a module library with a name from within IDEA. So what > the plugin is using here is an undocumented feature that leads to strange > results. > The solution is to add the module libraries without the name attribute and to > add the WebModule containerElements without a name too. Instead the jar URL > is added to the containerElement. > see applied patch > Cheers, > Manfred -- 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: (MWAR-23) war plugin doesn't copy dependencies with system scope
[ http://jira.codehaus.org/browse/MWAR-23?page=comments#action_61515 ]
John Tolentino commented on MWAR-23:
While debugging through maven-war-plugin, I noticed that project.getArtifacts()
did not include the artifacts with system scope. This means that adding:
public void buildWebapp( MavenProject project, File webappDirectory )
throws MojoExecutionException, IOException
{
...
ScopeArtifactFilter runtimeFilter = new ScopeArtifactFilter(
Artifact.SCOPE_RUNTIME );
ScopeArtifactFilter systemFilter = new ScopeArtifactFilter(
Artifact.SCOPE_SYSTEM );
if ( !artifact.isOptional() && ( runtimeFilter.include( artifact )
|| systemFilter.include( artifact ) ) )
...
}
won't work. There are two options to solve this:
1. Modify Maven 2 core to include artifacts in project.getArtifacts()
2. Go through the dependency list and individually fetch the artifacts with
system scope.
#2 is a more complicated solution because we have to check through the
inclusions/exclusions list and won't reuse existing framework to properly
filter artifacts. There is also duplication in the code.
#1 however won't be in time for the Maven 2.0.3 release because the versions to
be included in that release is already decided on.
I suggest we move this issue to the next release.
> war plugin doesn't copy dependencies with system scope
> --
>
> Key: MWAR-23
> URL: http://jira.codehaus.org/browse/MWAR-23
> Project: Maven 2.x War Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Dan Diephouse
> Assignee: John Tolentino
> Priority: Minor
> Fix For: 2.0
>
>
> I set about trying to include a jar that is not in the repository (either
> local or remote) and I ended up using the element with a scope
> of system for the dependency. Unfortunately the maven war plugin doesn't copy
> the jar to the war. I see two solutions:
> 1. Change the war plugin so it is included
> 2. Provide some mechanism to include jars on the filesystem in arbitrary
> places without a scope of system
--
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-1656) xml-apis relocation wrong
[ http://jira.codehaus.org/browse/MNG-1656?page=comments#action_61519 ] Julien HENRY commented on MNG-1656: --- It's not fixed for me with maven 2.0.2. [WARNING] While downloading xml-apis:xml-apis:2.0.2 This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > xml-apis relocation wrong > - > > Key: MNG-1656 > URL: http://jira.codehaus.org/browse/MNG-1656 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0 > Reporter: Jorg Heymans > Assignee: John Casey > Priority: Critical > Fix For: 2.0.1 > Attachments: log.txt > > Original Estimate: 3 hours >Time Spent: 3 hours > Remaining: 0 minutes > > During my build, i get this multiple times : > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > Even though i have directly specified xml-apis:xml-apis:1.3.02 in my pom, > maven insists on using 1.0.b2, making my build fail. > Steps to reproduce > 1) svn co > http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/ > testbug > 2) edit settings.xml to point to a clean repo > 3) mvn -N -s settings.xml install > 4) cd cocoon-core > 5) mvn -s ..\settings.xml -Dmaven.test.skip=true compile > This should fail with : > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[26,19] cannot resolve symbol > symbol : class DOMConfiguration > location: package dom > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[39,19] cannot resolve symbol > symbol : class UserDataHandler > location: package dom > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[914,11] cannot resolve symbol > symbol : class DOMConfiguration > location: class org.apache.cocoon.xml.dom.DocumentWrapper > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[1012,56] cannot resolve symbol > symbol : class UserDataHandler > location: class org.apache.cocoon.xml.dom.DocumentWrapper > The interfaces it can't find are effectively in 1.3.02 , but not in 1.0.b2 -- 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-1656) xml-apis relocation wrong
[ http://jira.codehaus.org/browse/MNG-1656?page=comments#action_61522 ] Julien HENRY commented on MNG-1656: --- Sorry, don't give attention to my last post. My problem was with pull-parser. > xml-apis relocation wrong > - > > Key: MNG-1656 > URL: http://jira.codehaus.org/browse/MNG-1656 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Versions: 2.0 > Reporter: Jorg Heymans > Assignee: John Casey > Priority: Critical > Fix For: 2.0.1 > Attachments: log.txt > > Original Estimate: 3 hours >Time Spent: 3 hours > Remaining: 0 minutes > > During my build, i get this multiple times : > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > Even though i have directly specified xml-apis:xml-apis:1.3.02 in my pom, > maven insists on using 1.0.b2, making my build fail. > Steps to reproduce > 1) svn co > http://svn.apache.org/repos/asf/cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/ > testbug > 2) edit settings.xml to point to a clean repo > 3) mvn -N -s settings.xml install > 4) cd cocoon-core > 5) mvn -s ..\settings.xml -Dmaven.test.skip=true compile > This should fail with : > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[26,19] cannot resolve symbol > symbol : class DOMConfiguration > location: package dom > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[39,19] cannot resolve symbol > symbol : class UserDataHandler > location: package dom > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[914,11] cannot resolve symbol > symbol : class DOMConfiguration > location: class org.apache.cocoon.xml.dom.DocumentWrapper > C:\temp\testtrunk\cocoon-core\src\main\java\org\apache\cocoon\xml\dom\DocumentWrapper.java > :[1012,56] cannot resolve symbol > symbol : class UserDataHandler > location: class org.apache.cocoon.xml.dom.DocumentWrapper > The interfaces it can't find are effectively in 1.3.02 , but not in 1.0.b2 -- 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-787) itext-1.3.6, itext 1.4
itext-1.3.6, itext 1.4 -- Key: MAVENUPLOAD-787 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-787 Project: maven-upload-requests Type: Wish Reporter: rupert thurner newer versions of itext: 1.3.6, and 1.4 would be great. -- 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-418) RSS feed for build status
[ http://jira.codehaus.org/browse/CONTINUUM-418?page=comments#action_61524 ] Adam Leggett commented on CONTINUUM-418: I have created a basic RssNotifier implementation that writes a build.rss to /rss continuum webapp context folder. It extends AbstractContinuumNotifier. I've modded the webapp appropriately. Am i duplicating effort here, or should i submit a patch? > RSS feed for build status > - > > Key: CONTINUUM-418 > URL: http://jira.codehaus.org/browse/CONTINUUM-418 > Project: Continuum > Type: Wish > Versions: 1.0 > Reporter: David Blevins > Priority: Minor > Attachments: rss.patch > > > Lyndon Samson suggested on the Geronimo dev list that an rss feed for > reporting build status would be a really great way to report build status. > A neat application of that feature would be the ability to include continuum > data on a confluence page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=comments#action_61526 ] Grzegorz Slowikowski commented on MAVENUPLOAD-780: -- maven-qalab-plugin-2.1.jar and maven-qalab-plugin-2.1-javadoc.jar have not been uploaded to http://www.ibiblio.org/maven2/net/objectlab/maven-qalab-plugin/2.1/ Reopen this issue and fix it please. > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- 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: (MEV-362) missing jar for relocation of netbeans:cvslib:3.6
missing jar for relocation of netbeans:cvslib:3.6 - Key: MEV-362 URL: http://jira.codehaus.org/browse/MEV-362 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: Olivier Lamy The pom says : 4.0.0 netbeans cvslib 3.6 org.netbeans lib But there is only a pom in http://www.ibiblio.org/maven2/org/netbeans/lib/3.6/. No 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: (MEV-362) missing jar for relocation of netbeans:cvslib:3.6
[ http://jira.codehaus.org/browse/MEV-362?page=comments#action_61527 ] Milos Kleint commented on MEV-362: -- Now even more strange is the fact that the cvs part of the name totally disappeared. What sense does a "lib" artifact in "org.netbeans" group have? close to none.. > missing jar for relocation of netbeans:cvslib:3.6 > - > > Key: MEV-362 > URL: http://jira.codehaus.org/browse/MEV-362 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: Olivier Lamy > > > The pom says : > > 4.0.0 > netbeans > cvslib > 3.6 > > > org.netbeans > lib > > > > But there is only a pom in > http://www.ibiblio.org/maven2/org/netbeans/lib/3.6/. > No jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-37) System properties not working during forking [surefire-testng branch, patch attached]
System properties not working during forking [surefire-testng branch, patch attached] - Key: SUREFIRE-37 URL: http://jira.codehaus.org/browse/SUREFIRE-37 Project: surefire Type: Bug Reporter: Christian Schulte Assigned to: Jason van Zyl Attachments: systemproperties.patch Hi, just started to try the surefire-testng branch and the maven-surefire-testng plugin. When setting system properties to the ForkConfiguration a new Properties instance is created taking the properties as the defaults. When this properties are written to disk using properties.store() the defaults are not written to disk. The attached patch changes ForkConfiguration.setSystemProperties( systemProperties) from this.systemProperties = new Properties( systemProperties ) to this.systemProperties = (Properties) systemProperties.clone() and makes system properties work during forking. -- 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-788) Databinder 0.4 upload request
Databinder 0.4 upload request - Key: MAVENUPLOAD-788 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-788 Project: maven-upload-requests Type: Task Reporter: Nathan Hamblen Please upload with sources, and also this archetype: http://databinder.net/releases/data-app-0.4-bundle.jar Note that Databinder depends on Wicket 1.2 beta2, requested for upload here: http://jira.codehaus.org/browse/MAVENUPLOAD-786 -- 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-2160) Access Problem with viewcvs
Access Problem with viewcvs --- Key: MNG-2160 URL: http://jira.codehaus.org/browse/MNG-2160 Project: Maven 2 Type: Wish Components: Sites & Reporting Reporter: Rainer Wasserfuhr Priority: Trivial currently http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-core/ gives: An Exception Has Occurred Access to "maven/components/trunk/maven-core" is forbidden. HTTP Response Status 403 Forbidden Python Traceback Traceback (most recent call last): File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main request.run_viewcvs() File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 228, in run_viewcvs % self.where, '403 Forbidden') ViewCVSException: 403 Forbidden: Access to "maven/components/trunk/maven-core" is forbidden. -- 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: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=comments#action_61537 ] Andres March commented on MWAR-26: -- Is it not possible to submit an issue for maven and get them to upgrade to 1.2. If not, will you accept a patch that does not require an upgrade? It may be a bit more code but this is a pretty important feature IMHO. > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-26-maven-war-plugin-2.diff, MWAR-26-maven-war-plugin.diff > > Time Spent: 3 hours, 40 minutes >Remaining: 0 minutes > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a patch. -- 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: (MSUREFIRE-81) In forked modes, many API jars cannot be used due to problems loading QName class
In forked modes, many API jars cannot be used due to problems loading QName class - Key: MSUREFIRE-81 URL: http://jira.codehaus.org/browse/MSUREFIRE-81 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.2 Environment: Linux, JDK 1.5.0_06 Reporter: Daniel Kulp Priority: Critical JDK 1.5.0 includes the javax.xml.QName class. However, a lot of jars (like stax-api, various xml jars, axis, etc...) also contain the class. In non-fork mode, everything works find and referencing a QName object loads the JDK provided one.In fork mode, you end up with errors like: java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class or java.lang.NoClassDefFoundError when loading the QName. This makes it nearly impossible to test various XML related technologies with JDK 1.5.0 in fork mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2161) [maven-embedder-refactor] values from settings.xml never used
[maven-embedder-refactor] values from settings.xml never used - Key: MNG-2161 URL: http://jira.codehaus.org/browse/MNG-2161 Project: Maven 2 Type: Bug Components: Embedding Versions: 2.1 Environment: jason's embedder refactor branch Reporter: Milos Kleint Attachments: settings.patch The CommonMavenObjectFactory create Settings object based on the parameters like settings locations, that fine, but also takes the offline state and usage of plugin regisry as parameters. However these values are also defined in the settings.xml file. 1. It turns into a Chicken-Egg problem, because I need the settings parsed to know the value (if user doens't specify on command line). 2. Or I can go with some defaults + user command line input.. Then the settings values are never used. patch containing alternate method included. Old one kept. Should be also exposed via the MavenEmbedder class o the outside. -- 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-16) mvn command gives a Null Pointer Exception after configuring plugins
mvn command gives a Null Pointer Exception after configuring plugins Key: MPLUGIN-16 URL: http://jira.codehaus.org/browse/MPLUGIN-16 Project: Maven 2.x Plugin Plugin Type: Bug Environment: Windows XP, Mavne 2.0.2 Reporter: Kin Leung Attachments: pom.xml I tried to use xdoclet with Maven 2.0.2 by adding those lines in pom.xml: bookstore-web xdoclet maven-xdoclet-plugin 1.2 generate-deployment-decriptor generate-sources web.xml src/main/webapp/WEB-INF webdoclet After I saved the file and run mvn (mvn install and mvn clean), it gives me Null Pointer Exception: Downloading: http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave n-xdoclet-plugin-1.2.pom 159b downloaded Downloading: http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave n-xdoclet-plugin-1.2.jar 34K downloaded [INFO] - --- [ERROR] FATAL ERROR [INFO] - --- [INFO] null [INFO] - --- [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM anager.java:295) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De faultPluginManager.java:200) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug inManager.java:165) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa ultLifecycleExecutor.java:1218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifec ycle(DefaultLifecycleExecutor.java:1182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl eMappings(DefaultLifecycleExecutor.java:950) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:450) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] - --- Looks like something is screwed up when maven attempts to run the plugin for generating the web.xml of my servlet. I didn't do anything on the settings.xml, does that matter? Also the documentation is por and in worse case the poor documentation offsets the benefits of the tool. -- 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: (MPSIMIAN-16) plugin:deregister does not work
plugin:deregister does not work --- Key: MPSIMIAN-16 URL: http://jira.codehaus.org/browse/MPSIMIAN-16 Project: maven-simian-plugin Type: Bug Versions: 1.6 Reporter: Lukas Theussl Assigned to: Lukas Theussl Fix For: 1.6.1 The 'name' attributes in doc:registerReport and doc:deregisterReport do not match. -- 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: (MPSIMIAN-16) plugin:deregister does not work
[ http://jira.codehaus.org/browse/MPSIMIAN-16?page=all ] Lukas Theussl closed MPSIMIAN-16: - Resolution: Fixed > plugin:deregister does not work > --- > > Key: MPSIMIAN-16 > URL: http://jira.codehaus.org/browse/MPSIMIAN-16 > Project: maven-simian-plugin > Type: Bug > Versions: 1.6 > Reporter: Lukas Theussl > Assignee: Lukas Theussl > Fix For: 1.6.1 > > > The 'name' attributes in doc:registerReport and doc:deregisterReport do not > match. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-170) SvnTagCommand doesn't work?
[ http://jira.codehaus.org/browse/SCM-170?page=comments#action_61550 ]
Alex Boisvert commented on SCM-170:
---
I am also experiencing this problem with a pom.xml that has tagBase parameter
defined.
> SvnTagCommand doesn't work?
> ---
>
> Key: SCM-170
> URL: http://jira.codehaus.org/browse/SCM-170
> Project: Maven SCM
> Type: Bug
> Reporter: Gareth Williams
> Priority: Critical
>
>
> mvn release:prepare fails with the following output:
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Local, non-commit operations do not take a log message
> Have looked at source, and suspect SvnTagCommand needs to be fixed - in SVN
> the copy command does not accept a log message
> Package: org.apache.maven.scm.provider.svn.svnexe.command.tag
> Class:SvnTagCommand
> private static Commandline createCommandLine( SvnScmProviderRepository
> repository, File workingDirectory,
> String tag, File
> messageFile )
> {
> cl.createArgument().setValue( "copy" );
> XXXcl.createArgument().setValue( "--file" );
> XXXcl.createArgument().setValue( messageFile.getAbsolutePath() );
>
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SCM-170) SvnTagCommand doesn't work?
[ http://jira.codehaus.org/browse/SCM-170?page=comments#action_61554 ]
Alex Boisvert commented on SCM-170:
---
Turns out my tagBase contained the 'scm:svn:..." prefix which shouldn't appear
on tagBase. Never mind my previous comment.
> SvnTagCommand doesn't work?
> ---
>
> Key: SCM-170
> URL: http://jira.codehaus.org/browse/SCM-170
> Project: Maven SCM
> Type: Bug
> Reporter: Gareth Williams
> Priority: Critical
>
>
> mvn release:prepare fails with the following output:
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Local, non-commit operations do not take a log message
> Have looked at source, and suspect SvnTagCommand needs to be fixed - in SVN
> the copy command does not accept a log message
> Package: org.apache.maven.scm.provider.svn.svnexe.command.tag
> Class:SvnTagCommand
> private static Commandline createCommandLine( SvnScmProviderRepository
> repository, File workingDirectory,
> String tag, File
> messageFile )
> {
> cl.createArgument().setValue( "copy" );
> XXXcl.createArgument().setValue( "--file" );
> XXXcl.createArgument().setValue( messageFile.getAbsolutePath() );
>
> }
--
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: (MASSEMBLY-74) MANIFEST.MF is not used when specified in configuration.
MANIFEST.MF is not used when specified in configuration.
Key: MASSEMBLY-74
URL: http://jira.codehaus.org/browse/MASSEMBLY-74
Project: Maven 2.x Assembly Plugin
Type: Bug
Reporter: Napoleon Esmundo C. Ramirez
If a project is assembled this way, the MANIFEST.MF is not used.
...
maven-assembly-plugin
jar-with-dependencies
${basedir}/src/main/resources/META-INF/MANIFEST.MF
...
--
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: (MASSEMBLY-74) MANIFEST.MF is not used when specified in configuration.
[ http://jira.codehaus.org/browse/MASSEMBLY-74?page=all ]
Napoleon Esmundo C. Ramirez updated MASSEMBLY-74:
-
Attachment: MASSEMBLY-74-maven-assembly-plugin.patch
> MANIFEST.MF is not used when specified in configuration.
>
>
> Key: MASSEMBLY-74
> URL: http://jira.codehaus.org/browse/MASSEMBLY-74
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Napoleon Esmundo C. Ramirez
> Attachments: MASSEMBLY-74-maven-assembly-plugin.patch
>
>
> If a project is assembled this way, the MANIFEST.MF is not used.
>
> ...
>
>
>
> maven-assembly-plugin
>
> jar-with-dependencies
>
>
> ${basedir}/src/main/resources/META-INF/MANIFEST.MF
>
>
>
>
>
> ...
>
--
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: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=comments#action_61556 ] John Tolentino commented on MWAR-26: Maven 2.0.3 was already voted on for release. That email was sent by John Casey to maven developers list, subject is [vote] Release Maven 2.0.3 (third RC). So the libraries used in that 2.0.3 won't have any more changes. There will still be a patch for maven-war-plugin in time for its 2.0 release though. Instead of having the code in plexus-utils, it will be in the war plugin. We'll just have to apply the first patch when maven changes the plexus-utils version that it uses to 1.2. > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-26-maven-war-plugin-2.diff, MWAR-26-maven-war-plugin.diff > > Time Spent: 3 hours, 40 minutes >Remaining: 0 minutes > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=all ] Carlos Sanchez reopened MAVENUPLOAD-780: > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- 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: (MWAR-23) war plugin doesn't copy dependencies with system scope
[ http://jira.codehaus.org/browse/MWAR-23?page=all ] Brett Porter updated MWAR-23: - Fix Version: (was: 2.0) I don't like either of those solutions :( We should tihnk about this some more. I'm not that happy about including system scope dependencies in the JAR based on what they were intended to be used for, so maybe Dan's use case should be addressed differently. > war plugin doesn't copy dependencies with system scope > -- > > Key: MWAR-23 > URL: http://jira.codehaus.org/browse/MWAR-23 > Project: Maven 2.x War Plugin > Type: Bug > Versions: 2.0 > Reporter: Dan Diephouse > Assignee: John Tolentino > Priority: Minor > > Time Spent: 3 hours >Remaining: 0 minutes > > I set about trying to include a jar that is not in the repository (either > local or remote) and I ended up using the element with a scope > of system for the dependency. Unfortunately the maven war plugin doesn't copy > the jar to the war. I see two solutions: > 1. Change the war plugin so it is included > 2. Provide some mechanism to include jars on the filesystem in arbitrary > places without a scope of system -- 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: (MSUREFIRE-81) In forked modes, many API jars cannot be used due to problems loading QName class
[ http://jira.codehaus.org/browse/MSUREFIRE-81?page=comments#action_61558 ] Carlos Sanchez commented on MSUREFIRE-81: - Can you try setting true in the surefire plugin configuration? > In forked modes, many API jars cannot be used due to problems loading QName > class > - > > Key: MSUREFIRE-81 > URL: http://jira.codehaus.org/browse/MSUREFIRE-81 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.2 > Environment: Linux, JDK 1.5.0_06 > Reporter: Daniel Kulp > Priority: Critical > > > JDK 1.5.0 includes the javax.xml.QName class. However, a lot of jars (like > stax-api, various xml jars, axis, etc...) also contain the class. In > non-fork mode, everything works find and referencing a QName object loads the > JDK provided one.In fork mode, you end up with errors like: > java.lang.LinkageError: loader constraints violated when linking > javax/xml/namespace/QName class > or java.lang.NoClassDefFoundError when loading the QName. This makes it > nearly impossible to test various XML related technologies with JDK 1.5.0 in > fork mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-780) Please upload the following QALab bundles - they are updated versions of the various QALab parts.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-780?page=all ] Carlos Sanchez closed MAVENUPLOAD-780: -- Resolution: Fixed will be there in the next hours > Please upload the following QALab bundles - they are updated versions of the > various QALab parts. > - > > Key: MAVENUPLOAD-780 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-780 > Project: maven-upload-requests > Type: Task > Reporter: Dave Sag > Assignee: Carlos Sanchez > Attachments: maven-qalab-plugin-0.8.0-bundle.jar, > maven-qalab-plugin-2.1-bundle.jar, qalab-0.8.0-bundle.jar > > > qalab-0.8.0 the latest release of QALab - the software quality data > aggregation and reporting utility. > maven-qalab-plugin-0.8.0 - a maven 1 plugin that uses qalab 0.8 > maven-qalab-plugin-2.1 a maven 2 plugin that uses qalab 0.8 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-787) itext-1.3.6, itext 1.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-787?page=comments#action_61560 ] Carlos Sanchez commented on MAVENUPLOAD-787: Please read http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > itext-1.3.6, itext 1.4 > -- > > Key: MAVENUPLOAD-787 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-787 > Project: maven-upload-requests > Type: Wish > Reporter: rupert thurner > > > newer versions of itext: 1.3.6, and 1.4 would be great. -- 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: (MASSEMBLY-74) MANIFEST.MF is not used when specified in configuration.
[ http://jira.codehaus.org/browse/MASSEMBLY-74?page=all ]
Napoleon Esmundo C. Ramirez updated MASSEMBLY-74:
-
Attachment: MASSEMBLY-74-maven-assembly-plugin.patch
> MANIFEST.MF is not used when specified in configuration.
>
>
> Key: MASSEMBLY-74
> URL: http://jira.codehaus.org/browse/MASSEMBLY-74
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Napoleon Esmundo C. Ramirez
> Attachments: MASSEMBLY-74-maven-assembly-plugin.patch,
> MASSEMBLY-74-maven-assembly-plugin.patch
>
>
> If a project is assembled this way, the MANIFEST.MF is not used.
>
> ...
>
>
>
> maven-assembly-plugin
>
> jar-with-dependencies
>
>
> ${basedir}/src/main/resources/META-INF/MANIFEST.MF
>
>
>
>
>
> ...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-784) Please upload maven-qalab-plugin 0.8.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-784?page=comments#action_61562 ] Carlos Sanchez commented on MAVENUPLOAD-784: This is already uploaded under net.objectlab group > Please upload maven-qalab-plugin 0.8.0 > -- > > Key: MAVENUPLOAD-784 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-784 > Project: maven-upload-requests > Type: Task > Reporter: Benoit Xhenseval > Attachments: maven-qalab-plugin-0.8.0-bundle.jar > > > it is a Maven 1.x plugin > Thanks! > Benoit -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-783) Please upload QALAb 0.8.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-783?page=comments#action_61563 ] Carlos Sanchez commented on MAVENUPLOAD-783: This is already uploaded under net.objectlab group > Please upload QALAb 0.8.0 > - > > Key: MAVENUPLOAD-783 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-783 > Project: maven-upload-requests > Type: Task > Reporter: Benoit Xhenseval > Attachments: qalab-0.8.0-bundle.jar > > > Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-782) A framework for home automation based the the xPL protocol.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-782?page=all ] Carlos Sanchez closed MAVENUPLOAD-782: -- Assign To: Carlos Sanchez Resolution: Fixed > A framework for home automation based the the xPL protocol. > --- > > Key: MAVENUPLOAD-782 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-782 > Project: maven-upload-requests > Type: Task > Reporter: Fredrik Aubert > Assignee: Carlos Sanchez > > > http://home.broadpark.no/~faubert/xpl/xpl4java-1.3h-bundle.jar > http://www.xpl4java.org > http://wiki.xplproject.org.uk > xPL is an open protocol intended to permit the control and monitoring of home > automation devices. xPL4Java is a collections of applications, tools and > framework for running xPL applications on any platform that supports Java. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-785) Java Tree Builder 1.3.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-785?page=comments#action_61564 ] Carlos Sanchez commented on MAVENUPLOAD-785: if it's hosted in http://compilers.cs.ucla.edu/jtb/ why that groupid? (note that package name by itself is not a good reson as explained in http://maven.apache.org/guides/mini/guide-ibiblio-upload.html) > Java Tree Builder 1.3.2 > --- > > Key: MAVENUPLOAD-785 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-785 > Project: maven-upload-requests > Type: Task > Reporter: Greg Kick > > > JTB is a syntax tree builder to be used with the Java Compiler Compiler > (JavaCC) parser generator. > It is often used as an alternatvie to JJTree due to it's ease of use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-54) Unable to filter files while creating assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-54?page=comments#action_61565 ] Allan Ramirez commented on MASSEMBLY-54: just tested the resource filtering and it is working fine with me. can you attach your use case? > Unable to filter files while creating assembly > -- > > Key: MASSEMBLY-54 > URL: http://jira.codehaus.org/browse/MASSEMBLY-54 > Project: Maven 2.x Assembly Plugin > Type: Improvement > Versions: 2.0 > Reporter: Chris Hagmann > Fix For: 2.1 > > > It doesn't seem to be possible to use filtering when creating assemblies. I > have a couple of plain-text files which need to be updated when creating the > assembly (e.g. README.TXT, .version). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-81) In forked modes, many API jars cannot be used due to problems loading QName class
[ http://jira.codehaus.org/browse/MSUREFIRE-81?page=comments#action_61566 ] Daniel Kulp commented on MSUREFIRE-81: -- Didn't help at all. Nothing changed. > In forked modes, many API jars cannot be used due to problems loading QName > class > - > > Key: MSUREFIRE-81 > URL: http://jira.codehaus.org/browse/MSUREFIRE-81 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.2 > Environment: Linux, JDK 1.5.0_06 > Reporter: Daniel Kulp > Priority: Critical > > > JDK 1.5.0 includes the javax.xml.QName class. However, a lot of jars (like > stax-api, various xml jars, axis, etc...) also contain the class. In > non-fork mode, everything works find and referencing a QName object loads the > JDK provided one.In fork mode, you end up with errors like: > java.lang.LinkageError: loader constraints violated when linking > javax/xml/namespace/QName class > or java.lang.NoClassDefFoundError when loading the QName. This makes it > nearly impossible to test various XML related technologies with JDK 1.5.0 in > fork mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-74) MANIFEST.MF is not used when specified in configuration.
[ http://jira.codehaus.org/browse/MASSEMBLY-74?page=all ]
Allan Ramirez updated MASSEMBLY-74:
---
Fix Version: 2.1
> MANIFEST.MF is not used when specified in configuration.
>
>
> Key: MASSEMBLY-74
> URL: http://jira.codehaus.org/browse/MASSEMBLY-74
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Napoleon Esmundo C. Ramirez
> Fix For: 2.1
> Attachments: MASSEMBLY-74-maven-assembly-plugin.patch,
> MASSEMBLY-74-maven-assembly-plugin.patch
>
>
> If a project is assembled this way, the MANIFEST.MF is not used.
>
> ...
>
>
>
> maven-assembly-plugin
>
> jar-with-dependencies
>
>
> ${basedir}/src/main/resources/META-INF/MANIFEST.MF
>
>
>
>
>
> ...
>
--
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: (MSUREFIRE-81) In forked modes, many API jars cannot be used due to problems loading QName class
[ http://jira.codehaus.org/browse/MSUREFIRE-81?page=comments#action_61567 ] Daniel Kulp commented on MSUREFIRE-81: -- false did work. This should definitely be the default for fork modes.Having tests not pass in fork mode that pass fine in non-fork mode is not a good situation. > In forked modes, many API jars cannot be used due to problems loading QName > class > - > > Key: MSUREFIRE-81 > URL: http://jira.codehaus.org/browse/MSUREFIRE-81 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.2 > Environment: Linux, JDK 1.5.0_06 > Reporter: Daniel Kulp > Priority: Critical > > > JDK 1.5.0 includes the javax.xml.QName class. However, a lot of jars (like > stax-api, various xml jars, axis, etc...) also contain the class. In > non-fork mode, everything works find and referencing a QName object loads the > JDK provided one.In fork mode, you end up with errors like: > java.lang.LinkageError: loader constraints violated when linking > javax/xml/namespace/QName class > or java.lang.NoClassDefFoundError when loading the QName. This makes it > nearly impossible to test various XML related technologies with JDK 1.5.0 in > fork mode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-79) exclude dependencies from the Classpath Container
exclude dependencies from the Classpath Container - Key: MECLIPSE-79 URL: http://jira.codehaus.org/browse/MECLIPSE-79 Project: Maven 2.x Eclipse Plugin Type: Improvement Environment: Windows, Eclipse 3.1.2 Reporter: Martin Goldhahn There are some dependencies that need to be in the POM in order to compile the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an error because the servlet classes from the POM are included in the classpath via the classpath 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
