[jira] Commented: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=comments#action_72644 ] Anders Sveen commented on MPCHECKSTYLE-20: -- I'm not sure but I think it is the same error. I get the same error on ServletException (which is in the classpath) and it only happens on my build server. My development PC with Windows works just fine. I'm on Maven 2.0.3. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: maven-checkstyle-plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-727) Allow Continuum to work with the release plugin to perform the official release
[ http://jira.codehaus.org/browse/CONTINUUM-727?page=comments#action_72647 ] Brett Porter commented on CONTINUUM-727: http://mail-archives.apache.org/mod_mbox/maven-continuum-dev/200606.mbox/[EMAIL PROTECTED] > Allow Continuum to work with the release plugin to perform the official > release > --- > > Key: CONTINUUM-727 > URL: http://jira.codehaus.org/browse/CONTINUUM-727 > Project: Continuum > Issue Type: New Feature > Components: Core system >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > Fix For: 1.1 > > > This might eventually be a little tool for release management but it could > start in Continuum. So the release plugin would do a release:prepare and > store the information in a descriptor (maybe use modello to describe the > release) and the descriptor could be sent to Continuum via a Web Service and > Continuum could do the official release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-292) implement group summary page
[ http://jira.codehaus.org/browse/CONTINUUM-292?page=all ] Maria Odea Ching updated CONTINUUM-292: --- Due Date: 29/Aug/06 Remaining Estimate: 20 hours Original Estimate: 20 hours > implement group summary page > > > Key: CONTINUUM-292 > URL: http://jira.codehaus.org/browse/CONTINUUM-292 > Project: Continuum > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Original Estimate: 20 hours > Remaining Estimate: 20 hours > > http://people.apache.org/~brett/white-site/viewGroup.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: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=comments#action_72654 ] Anders Sveen commented on MPCHECKSTYLE-20: -- Changing the scope from provided to compile fixed the problem. It makes maven include the file in the war, but for the Servlet API that's no biggie. Other libs might cause more trouble. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: maven-checkstyle-plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-822) Create acegi acl tables on database creation
[ http://jira.codehaus.org/browse/CONTINUUM-822?page=all ] Napoleon Esmundo C. Ramirez updated CONTINUUM-822: -- Attachment: CONTINUUM-822.patch I found a plugin repackaging of Ant's SQLExec task in codehaus, sql-maven-plugin. The acegi branch is broken at the moment, so this patch hasn't been tested yet. > Create acegi acl tables on database creation > > > Key: CONTINUUM-822 > URL: http://jira.codehaus.org/browse/CONTINUUM-822 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Napoleon Esmundo C. Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-822.patch > > > The SQL script is in continuum-security-acegi > src/main/resources > org.apache.maven.continuum.security.acegi.acl.acegi-acl-derby.sql > This needs to be run against the db when the database is created. I think > there's a sql plugin for maven somewhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-747) Continuum can't add a project with pom in https with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-747?page=all ] Lester Ecarma updated CONTINUUM-747: Attachment: CONTINUUM-747.patch Attached patch should fix this. > Continuum can't add a project with pom in https with authentication > --- > > Key: CONTINUUM-747 > URL: http://jira.codehaus.org/browse/CONTINUUM-747 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 >Reporter: Carlos Sanchez > Assigned To: Joakim Erdfelt >Priority: Critical > Fix For: 1.1 > > Attachments: CONTINUUM-747.patch > > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > When trying to add a project with this type of url > https://username:[EMAIL PROTECTED]/foo/trunk/pom.xml > I get a 401 Unauthorized HTTP error code > Seems that the problem is in > http://svn.codehaus.org/plexus/trunk/plexus-components/plexus-formica/src/main/java/org/codehaus/plexus/formica/util/MungedHttpsURL.java > I added a test case with the right url and get that 401 too -- 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-292) implement group summary page
[ http://jira.codehaus.org/browse/CONTINUUM-292?page=comments#action_72662 ] Brett Porter commented on CONTINUUM-292: isn't this something Jesse just implemented? > implement group summary page > > > Key: CONTINUUM-292 > URL: http://jira.codehaus.org/browse/CONTINUUM-292 > Project: Continuum > Issue Type: New Feature >Reporter: Brett Porter > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Original Estimate: 20 hours > Remaining Estimate: 20 hours > > http://people.apache.org/~brett/white-site/viewGroup.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: (SUREFIRE-53) context classloader not always reset to original values
context classloader not always reset to original values --- Key: SUREFIRE-53 URL: http://jira.codehaus.org/browse/SUREFIRE-53 Project: surefire Issue Type: Bug Reporter: Milos Kleint Attachments: surefirebooter.patch in case of exception during test execution in surefire booter, the context classloader is not reset to original value.. patch simple -attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-240) Absolute links bypass mod_proxy
[ http://jira.codehaus.org/browse/CONTINUUM-240?page=comments#action_72666 ] Jens Reimann commented on CONTINUUM-240: Is there any progress here? This issue prevents me from using HTTPS. Not having HTTPS is a real problem when you need users to log in and transmit passwords! > Absolute links bypass mod_proxy > > > Key: CONTINUUM-240 > URL: http://jira.codehaus.org/browse/CONTINUUM-240 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0-alpha-3 >Reporter: Björn Sköld > Assigned To: Trygve Laugstol >Priority: Minor > Fix For: 1.0-alpha-4 > > > Continuum does not work with the mod_proxy config shown in site docs: > ProxyPass /continuum http://localhost:8080/continuum/ > ProxyPassReverse /continuum http://localhost:8080/continuum/ > All links in the continuum webapp are absolute, and ProxyPassReverse only > does rewrite of headers, not page content. > This means that clicking on one of continuums links bypasses the proxy and > goes directly to localhost:8080/continuum/. > There is a 3rd-party module (mod_proxy_html) that does rewrite of page > content, but it seems like a waste of CPU cycles. > Making continuum generate relative links would probably be more efficient. > http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypassreverse -- 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-240) Absolute links bypass mod_proxy
[ http://jira.codehaus.org/browse/CONTINUUM-240?page=comments#action_72667 ] Jens Reimann commented on CONTINUUM-240: It looks like as if the following apache configuration can work around this bug: ProxyPass http://localhost:8090/continuum/ ProxyPassReverse http://localhost:8090/continuum/ SetOutputFilter proxy-html ProxyHTMLURLMap http://localhost:80/continuum/ / ProxyHTMLURLMap http://localhost/continuum/ / Using the following as webapp configuration: 8090 localhost 80 Interstingly both mappings must be configured since some generated URLs include the port while others do not. This is really ugly!! > Absolute links bypass mod_proxy > > > Key: CONTINUUM-240 > URL: http://jira.codehaus.org/browse/CONTINUUM-240 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0-alpha-3 >Reporter: Björn Sköld > Assigned To: Trygve Laugstol >Priority: Minor > Fix For: 1.0-alpha-4 > > > Continuum does not work with the mod_proxy config shown in site docs: > ProxyPass /continuum http://localhost:8080/continuum/ > ProxyPassReverse /continuum http://localhost:8080/continuum/ > All links in the continuum webapp are absolute, and ProxyPassReverse only > does rewrite of headers, not page content. > This means that clicking on one of continuums links bypasses the proxy and > goes directly to localhost:8080/continuum/. > There is a 3rd-party module (mod_proxy_html) that does rewrite of page > content, but it seems like a waste of CPU cycles. > Making continuum generate relative links would probably be more efficient. > http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypassreverse -- 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: (MPWAR-62) maven-war-plugin doesn't compile java sources when used with maven-test-plugin 1.8
[ http://jira.codehaus.org/browse/MPWAR-62?page=all ] nicolas de loof reopened MPWAR-62: -- Sounds like latests comments on this issue had no effect on SVN. This issue is not yet fully solved. > maven-war-plugin doesn't compile java sources when used with > maven-test-plugin 1.8 > --- > > Key: MPWAR-62 > URL: http://jira.codehaus.org/browse/MPWAR-62 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: nicolas de loof > Assigned To: Lukas Theussl > Fix For: 1.6.3 > > Attachments: MPWAR-62, MPWAR-62.patch, MPWAR-62.patch > > > I've found an issue when using latest versions of maven-test-plugin (1.8) : > when maven.test.skip=true is set, the goal is not executed. > This sounds good, BUT the maven-war-plugin use "test:test" goal to attain the > "java:compile" goal, so the generated war has no classes ! > The war:resources plugin should have > prereqs="war:war-resources,*java:compile*,test: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] Commented: (MPECLIPSE-102) Running 'maven:eclipse' turns CheckStyle off for the project.
[ http://jira.codehaus.org/browse/MPECLIPSE-102?page=comments#action_72671 ] nicolas de loof commented on MPECLIPSE-102: --- You simply have to set : maven.eclipse.projectnatures = com.atlassw.tools.eclipse.checkstyle.CheckstyleNature maven.eclipse.buildcommands = com.atlassw.tools.eclipse.checkstyle.CheckstyleBuilder (and any other builders/nature for the plugins you like to use in Eclipse) > Running 'maven:eclipse' turns CheckStyle off for the project. > - > > Key: MPECLIPSE-102 > URL: http://jira.codehaus.org/browse/MPECLIPSE-102 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Jamie Bisotti > > Assuming project is already setup in Eclipse 3.1 (either manually or via the > eclipse plugin) > 1. Install CheckStyle Eclispe plugin > 2. Turn it on for the project. > 3. Shutdown Eclipse > 4. Run maven eclipse on the project > 5. Restart Eclipse > 6. Notice CheckStyle is now turned off. -- 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: (MPECLIPSE-123) javadoc jar is not attached to Eclipse
javadoc jar is not attached to Eclipse -- Key: MPECLIPSE-123 URL: http://jira.codehaus.org/browse/MPECLIPSE-123 Project: maven-eclipse-plugin Issue Type: Bug Affects Versions: 1.11 Reporter: nicolas de loof Priority: Minor Fix For: 1.11.1 latest Plugin doesn't attach javadoc jar in the Eclipse Classpath. This is caused by a copy/paste of the chek-file-exists block that doesn't use the "jdocs" variable. It would be great also to try downloading the javadocs when no sources jar is available : for example, the Oracle JDBC driver is closed-source but has javadoc that can be deployed in a corporate repository and be available to all corporate developpers. -- 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: (MPECLIPSE-123) javadoc jar is not attached to Eclipse
[ http://jira.codehaus.org/browse/MPECLIPSE-123?page=comments#action_72674 ] nicolas de loof commented on MPECLIPSE-123: --- Sory for bad diagnostic, I was reading a modified plugin.jelly, not the SVN one. According to plugin code, this is an expected behaviour as Eclipse before 3.2 doesn't support MAVEN_REPO classpath variable for javadoc attachement. Maybe a property could make use of javadocs jars optional ? Maybe an eclipse version property could be usefull for other goals in this plugin, and could enable javadocs attachement / download ? > javadoc jar is not attached to Eclipse > -- > > Key: MPECLIPSE-123 > URL: http://jira.codehaus.org/browse/MPECLIPSE-123 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.11 >Reporter: nicolas de loof >Priority: Minor > Fix For: 1.11.1 > > > latest Plugin doesn't attach javadoc jar in the Eclipse Classpath. This is > caused by a copy/paste of the chek-file-exists block that doesn't use the > "jdocs" variable. > It would be great also to try downloading the javadocs when no sources jar is > available : for example, the Oracle JDBC driver is closed-source but has > javadoc that can be deployed in a corporate repository and be available to > all corporate developpers. -- 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: (MPECLIPSE-123) javadoc jar is not attached to Eclipse
[ http://jira.codehaus.org/browse/MPECLIPSE-123?page=comments#action_72676 ] nicolas de loof commented on MPECLIPSE-123: --- It seems there not a better support for classpath variables for javadoc in Eclipse 3.2 > javadoc jar is not attached to Eclipse > -- > > Key: MPECLIPSE-123 > URL: http://jira.codehaus.org/browse/MPECLIPSE-123 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.11 >Reporter: nicolas de loof >Priority: Minor > Fix For: 1.11.1 > > > latest Plugin doesn't attach javadoc jar in the Eclipse Classpath. This is > caused by a copy/paste of the chek-file-exists block that doesn't use the > "jdocs" variable. > It would be great also to try downloading the javadocs when no sources jar is > available : for example, the Oracle JDBC driver is closed-source but has > javadoc that can be deployed in a corporate repository and be available to > all corporate developpers. -- 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-2515) The Embedder does not work when started from a groovy script that is started from maven 2
The Embedder does not work when started from a groovy script that is started from maven 2 - Key: MNG-2515 URL: http://jira.codehaus.org/browse/MNG-2515 Project: Maven 2 Issue Type: Bug Components: Embedding Affects Versions: 2.1 Environment: Windows XP, JDK 1.5, Maven 2.0.4 Reporter: Christian Domsch Attachments: embedder-it-test.zip The deploymentserver:changestage plugin starts a groovy script that again starts a maven 2.1-SNAPSHOT embedder. This fails due to classloading issues because the classloader for the groovy script contains a thread context classloader a s a parent. This parent classloader contains all classes from the maven 2.0.4 process that started the plugin. The embedder now fails to start because the parent classloader contains conflicting classes from 2.0.4 while the embedder is 2.1-SNAPSHOT. The test case in the zip contains the source for the deploymentserver-mojo and the projects that this mojo should operate on. To start the test, install the mojo, and start maven in the productA project with "mvn deploymentserver:changestage". For this to work the settings.xml must contain innowake.lifecycle.deployment.engine.plugin The zip also contains the groovy jars to be copied in the local repository. Greetings, Christian. -- 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-240) Absolute links bypass mod_proxy
[ http://jira.codehaus.org/browse/CONTINUUM-240?page=comments#action_72677 ] Jens Reimann commented on CONTINUUM-240: This is totally screwed up! You need to add: ProxyHTMLURlMap /continuum/images/ /images/ in order to get some of the images > Absolute links bypass mod_proxy > > > Key: CONTINUUM-240 > URL: http://jira.codehaus.org/browse/CONTINUUM-240 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0-alpha-3 >Reporter: Björn Sköld > Assigned To: Trygve Laugstol >Priority: Minor > Fix For: 1.0-alpha-4 > > > Continuum does not work with the mod_proxy config shown in site docs: > ProxyPass /continuum http://localhost:8080/continuum/ > ProxyPassReverse /continuum http://localhost:8080/continuum/ > All links in the continuum webapp are absolute, and ProxyPassReverse only > does rewrite of headers, not page content. > This means that clicking on one of continuums links bypasses the proxy and > goes directly to localhost:8080/continuum/. > There is a 3rd-party module (mod_proxy_html) that does rewrite of page > content, but it seems like a waste of CPU cycles. > Making continuum generate relative links would probably be more efficient. > http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypassreverse -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-182) Initialization of the artifact map, and initialization after cleaning.
Initialization of the artifact map, and initialization after cleaning. -- Key: MNGECLIPSE-182 URL: http://jira.codehaus.org/browse/MNGECLIPSE-182 Project: Maven 2.x Extension for Eclipse Issue Type: Sub-task Components: Dependency Resolver Reporter: Scott Cytacki Assigned To: Eugene Kuleshov I started on the initialization of the artifact map in the MaveModelManager. But it is getting a bit more complicated than I thought, and it seems different than what Euguene suggested. So I wanted to describe it before I go too much further. Here is the current design: MavenModelManager has an initialize() method that: * checks if it has been initialized before, if so it does nothing * traverses the projects in the workspace and a calls updateMavenModel for each pom it finds. the Job created in Maven2ClassContainerInitializer initialize() method calls initialize on the mavenModelManager Additionally there is the issue of when the workspace is cleaned. Here is the case: - project A depends on groupB:artifactB - the workspace becomes inconsistant, or the automatic building is turned off - project B is added to the workspace and its maven key is groupB:artifactB - now the workspace is cleaned The building process appears to decide the order of processing projects based on the dependency graph between the projects. In this case project A doesn't know it depends on B yet, so the builder might build project A first. In this case the poms in B won't be in the artifact map yet. So A won't add the project B as a dependency. I'm curious again how the PDE handles cases like this. Perhaps the best is to listen for the clean event and re-create the artifact map in the modelManager. -- 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: (MPECLIPSE-123) javadoc jar is not attached to Eclipse
[ http://jira.codehaus.org/browse/MPECLIPSE-123?page=all ] nicolas de loof updated MPECLIPSE-123: -- Attachment: MPECLIPSE-123.patch This patch enables javadocs downloading when sources are not available. javadoc jar is added to .classpath using an absolute path due to lack of support for MAVEN_REPO classpath variable in Eclipse. As this classpath file can easily be re-created, I don't think this is a good reason for blocking this functionnality. Patch contains code + doc improvement > javadoc jar is not attached to Eclipse > -- > > Key: MPECLIPSE-123 > URL: http://jira.codehaus.org/browse/MPECLIPSE-123 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.11 >Reporter: nicolas de loof >Priority: Minor > Fix For: 1.11.1 > > Attachments: MPECLIPSE-123.patch > > > latest Plugin doesn't attach javadoc jar in the Eclipse Classpath. This is > caused by a copy/paste of the chek-file-exists block that doesn't use the > "jdocs" variable. > It would be great also to try downloading the javadocs when no sources jar is > available : for example, the Oracle JDBC driver is closed-source but has > javadoc that can be deployed in a corporate repository and be available to > all corporate developpers. -- 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-139) Not all information from parent available in plugin?
Not all information from parent available in plugin?
Key: MASSEMBLY-139
URL: http://jira.codehaus.org/browse/MASSEMBLY-139
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Ernst Lindoorn
Attachments: project.zip
In a multimodule project, it seems that not all information of the parent
project is passed (or otherwise available) in the assembly plugin.
Given the attached minimalist setup, I echo the project.parent.name / version
and project.name / version.
During mvn assembly:assembly it seems the project.parent.name variable is not
available, while the version is.
Output:
[echo] Outputting some variables
[echo] `-> project.parent: ${project.parent.name} - 1.0-SNAPSHOT
[echo] `-> project: Module Name - 0.5-SNAPSHOT
Instead of the expected:
[echo] Outputting some variables
[echo] `-> project.parent: Project Name - 1.0-SNAPSHOT
[echo] `-> project: Module Name - 0.5-SNAPSHOT
--
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-2516) Central isn't checked if pluginRepo specified in pom isn't reachable
Central isn't checked if pluginRepo specified in pom isn't reachable Key: MNG-2516 URL: http://jira.codehaus.org/browse/MNG-2516 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Brian Fox Attachments: pom.xml, settings.xml I ran into a case where we have a repo defined in our pom. In some installations, this repo isn't reachable. To work around this, we synched our repo locally and setup file based remote repos and pluginrepos. However when checking for plugins, central wasn't being checked because it was stopping at the repo it couldn't reach. I was able to replicate this with a simple pom and settings.xml that are attached. Put them in a folder and run mvn -s ./settings.xml install. It seems like failures accessing one repo will cause the whole build to fail. Shouldn't it at least check other repos like central before giving up completely? -- 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: (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=comments#action_72692 ] Lukas Theussl commented on MPCHECKSTYLE-20: --- Please note that this issue is for the Maven 1 checkstyle plugin, for the m2 plugin you should go to http://jira.codehaus.org/browse/MCHECKSTYLE. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: maven-checkstyle-plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-183) Allow the selection of a POM in the local file system to setup the project in Eclipse
Allow the selection of a POM in the local file system to setup the project in Eclipse - Key: MNGECLIPSE-183 URL: http://jira.codehaus.org/browse/MNGECLIPSE-183 Project: Maven 2.x Extension for Eclipse Issue Type: New Feature Affects Versions: 0.0.10 Reporter: Jason van Zyl Assigned To: Eugene Kuleshov The easiest way to setup a Maven project in Eclipse would be to point at a POM in the local file 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] Created: (MNGECLIPSE-184) invalid relativePath references in pom causes an incorrectly handled NPE
invalid relativePath references in pom causes an incorrectly handled NPE Key: MNGECLIPSE-184 URL: http://jira.codehaus.org/browse/MNGECLIPSE-184 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Reporter: Scott Cytacki Assigned To: Eugene Kuleshov If the project.parent.relativePath is not valid the following NPE is thrown. The m2eclispe plugin currently handles this by displaying an error on the pom with a descrption of NullPointerException. It seems this is a bug in the maven embedder, but in the meantime the m2eclipse plugin could at least log the exception better. java.lang.NullPointerException at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1075) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:676) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:418) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:194) at org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:305) at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:330) at org.maven.ide.eclipse.Maven2Plugin$ReadProjectTask.run(Maven2Plugin.java:577) at org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:185) at org.maven.ide.eclipse.Maven2Plugin.resolveClasspathEntries(Maven2Plugin.java:388) at org.maven.ide.eclipse.Maven2Plugin.resolveClasspathEntries(Maven2Plugin.java:461) at org.maven.ide.eclipse.container.Maven2ClasspathContainerInitializer$1.run(Maven2ClasspathContainerInitializer.java:83) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -- 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: (MNGECLIPSE-183) Allow the selection of a POM in the local file system to setup the project in Eclipse
[ http://jira.codehaus.org/browse/MNGECLIPSE-183?page=comments#action_72694 ] Jason van Zyl commented on MNGECLIPSE-183: -- Would be nice to have a Maven icon in a visible place that would allow the selection of a POM so that the user doesn't have to explicity enable Maven for a project. > Allow the selection of a POM in the local file system to setup the project in > Eclipse > - > > Key: MNGECLIPSE-183 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-183 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature >Affects Versions: 0.0.10 >Reporter: Jason van Zyl > Assigned To: Eugene Kuleshov > > The easiest way to setup a Maven project in Eclipse would be to point at a > POM in the local file 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] Closed: (MPWAR-62) maven-war-plugin doesn't compile java sources when used with maven-test-plugin 1.8
[ http://jira.codehaus.org/browse/MPWAR-62?page=all ] Lukas Theussl closed MPWAR-62. -- Resolution: Fixed Sorry, please open a new issue with a detailed description of what exactly is still not working. > maven-war-plugin doesn't compile java sources when used with > maven-test-plugin 1.8 > --- > > Key: MPWAR-62 > URL: http://jira.codehaus.org/browse/MPWAR-62 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: nicolas de loof > Assigned To: Lukas Theussl > Fix For: 1.6.3 > > Attachments: MPWAR-62, MPWAR-62.patch, MPWAR-62.patch > > > I've found an issue when using latest versions of maven-test-plugin (1.8) : > when maven.test.skip=true is set, the goal is not executed. > This sounds good, BUT the maven-war-plugin use "test:test" goal to attain the > "java:compile" goal, so the generated war has no classes ! > The war:resources plugin should have > prereqs="war:war-resources,*java:compile*,test: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: (MAVENUPLOAD-1061) Upload qdox 1.6 on m2 repo
Upload qdox 1.6 on m2 repo -- Key: MAVENUPLOAD-1061 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1061 Project: maven-upload-requests Issue Type: Task Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-68) Adding twiki plugin as build extension makes goal site:site fail.
[ http://jira.codehaus.org/browse/DOXIA-68?page=comments#action_72698 ]
Vincent Siveton commented on DOXIA-68:
--
Without jxr, javadoc or other report plugin references (i.e. only and
tags), you should have this following:
{noformat}
[INFO] Error getting reports from the plugin
'org.apache.maven.plugins:maven-project-info-reports-plugin': Unable to find
the mojo
'org.apache.maven.plugins:maven-project-info-reports-plugin:2.1-SNAPSHOT:cim'
in the plugin 'org.apache.maven.plugins:maven-project-info-reports-plugin'
{noformat}
If you copy all reports plugins in tag, it should work:
{code:xml}
...
doxia-module-twiki
org.apache.maven.doxia
1.0-alpha-9-SNAPSHOT
org.apache.maven.plugins
maven-site-plugin
2.0-SNAPSHOT
org.apache.maven.plugins
maven-javadoc-plugin
2.1-SNAPSHOT
org.apache.maven.plugins
maven-project-info-reports-plugin
2.1-SNAPSHOT
...
org.apache.maven.plugins
maven-javadoc-plugin
2.1-SNAPSHOT
{code}
Twice plugin definition, we definitely need to review that.
> Adding twiki plugin as build extension makes goal site:site fail.
> -
>
> Key: DOXIA-68
> URL: http://jira.codehaus.org/browse/DOXIA-68
> Project: doxia
> Issue Type: Bug
> Components: Module - Twiki
>Affects Versions: 1.0-alpha-8
> Environment: WinXp, Java5
>Reporter: Martin Zeltner
>
> When I add the twiki module as an extension in my pom.xml the goal site:site
> will fail.
> Extension config snippet:
> --
>
>
>
>
> doxia-module-twiki
> org.apache.maven.doxia
> 1.0-alpha-9-SNAPSHOT
>
>
>
> --
> Console output:
> --
> mvn site:site -X
> + Error stacktraces are turned on.
> Maven version: 2.1-SNAPSHOT
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'site'.
> [INFO]
>
> [INFO] Building EL4J module core
> [INFO]task-segment: [site:site]
> [INFO]
>
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] **
> [INFO] Starting Jakarta Velocity v1.4
> [INFO] RuntimeInstance initializing.
> [INFO] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> [INFO] Default ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> [INFO] Resource Loader Instantiated:
> org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
> [INFO] ClasspathResourceLoader : initialization starting.
> [INFO] ClasspathResourceLoader : initialization complete.
> [INFO] ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> [INFO] Default ResourceManager initialization complete.
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [INFO] Created: 20 parsers.
> [INFO] Velocimacro : initialization starting.
> [INFO] Velocimacro : adding VMs from VM library template :
> VM_global_library.vm
> [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
> any resource loader.
> [INFO] Velocimacro : error using VM library template VM_global_library.vm :
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'VM_global_library.vm'
> [INFO] Velocimacro : VM library template macro registration complete.
> [INFO] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [INFO] Velocimacro : initialization complete.
> [INFO] Velocity successfully started.
> [INFO]
> ---
[jira] Commented: (MNGECLIPSE-183) Allow the selection of a POM in the local file system to setup the project in Eclipse
[ http://jira.codehaus.org/browse/MNGECLIPSE-183?page=comments#action_72699 ] Eugene Kuleshov commented on MNGECLIPSE-183: Not sure what your last comment mean. I can add some actions to the toolbar, but not sure what those actions should be. For now you can select multple projects and enable maven for all of them in one call. So, I don't really see a need for this action to stay on the screen all the time. Anyways, when import feature will be implemented maven will be enabled automatically. BTW, we have "New Maven project wizard" in the trunk. It will go into the next plugin release as soon as you sort out all the embedder stuff. > Allow the selection of a POM in the local file system to setup the project in > Eclipse > - > > Key: MNGECLIPSE-183 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-183 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature >Affects Versions: 0.0.10 >Reporter: Jason van Zyl > Assigned To: Eugene Kuleshov > > The easiest way to setup a Maven project in Eclipse would be to point at a > POM in the local file 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] Updated: (MNGECLIPSE-182) Initialization of the artifact map, and initialization after cleaning.
[ http://jira.codehaus.org/browse/MNGECLIPSE-182?page=all ] Scott Cytacki updated MNGECLIPSE-182: - Attachment: model-mananger-init-20060818-0.patch This patch takes care of the problems for me. It schedules a job for collecting all the poms in the workspace. It doesn't address the cleaning issue. It goes recursively into modules of the project poms. > Initialization of the artifact map, and initialization after cleaning. > -- > > Key: MNGECLIPSE-182 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-182 > Project: Maven 2.x Extension for Eclipse > Issue Type: Sub-task > Components: Dependency Resolver >Reporter: Scott Cytacki > Assigned To: Eugene Kuleshov > Attachments: model-mananger-init-20060818-0.patch > > > I started on the initialization of the artifact map in the MaveModelManager. > But it is getting a bit more complicated than I thought, and it seems > different than what Euguene suggested. So I wanted to describe it before I > go too much further. > Here is the current design: > MavenModelManager has an initialize() method that: > * checks if it has been initialized before, if so it does nothing > * traverses the projects in the workspace and a calls updateMavenModel for > each pom it finds. > the Job created in Maven2ClassContainerInitializer initialize() method calls > initialize on the mavenModelManager > Additionally there is the issue of when the workspace is cleaned. Here is > the case: > - project A depends on groupB:artifactB > - the workspace becomes inconsistant, or the automatic building is turned off > - project B is added to the workspace and its maven key is groupB:artifactB > - now the workspace is cleaned > The building process appears to decide the order of processing projects based > on the dependency graph between the projects. In this case project A doesn't > know it depends on B yet, so the builder might build project A first. In > this case the poms in B won't be in the artifact map yet. So A won't add the > project B as a dependency. I'm curious again how the PDE handles cases like > this. > Perhaps the best is to listen for the clean event and re-create the artifact > map in the modelManager. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_72701 ] Scott Cytacki commented on MNGECLIPSE-59: - I created a sub-task to work on the patch for initializing the artifact map: MNGECLIPSE-182 I've posted a patch there that takes care of it for me. Without this initialization there will be many broken dependencies especially if projects are only available in the ecipse workspace. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MAVEN-1704) artifactId is used as groupId when the latest is not defined
[ http://jira.codehaus.org/browse/MAVEN-1704?page=all ] Lukas Theussl updated MAVEN-1704: - Attachment: MAVEN-1704.tar.gz This is not what's happening in 11rc1: both parent and child projects have the *same* groupId (the parent's) if no groupId is defined in either of them. They were different in m1.0, so it's a problem. See attached test project. > artifactId is used as groupId when the latest is not defined > > > Key: MAVEN-1704 > URL: http://jira.codehaus.org/browse/MAVEN-1704 > Project: Maven > Issue Type: Bug > Components: inheritance >Affects Versions: 1.1-beta-2 >Reporter: Carlos Sanchez > Fix For: 1.1-rc1 > > Attachments: MAVEN-1704.tar.gz > > > artifactId is used as groupId when the latest is not defined (using extends > at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven > should complain. > Which is really a problem is that if pom a extends pom b, and no groupId is > defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, > while in 1.1 artifactId of b is the chosen 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] Updated: (MPWAR-61) Renaming jar file with war.target.pathfile
[ http://jira.codehaus.org/browse/MPWAR-61?page=all ]
Lukas Theussl updated MPWAR-61:
---
Fix Version/s: 1.6.3
> Renaming jar file with war.target.pathfile
> --
>
> Key: MPWAR-61
> URL: http://jira.codehaus.org/browse/MPWAR-61
> Project: maven-war-plugin
> Issue Type: Improvement
>Affects Versions: 1.6.1
> Environment: maven 1.x
> eclipse 3.1.2
>Reporter: hugo lassiege
>Priority: Trivial
> Fix For: 1.6.3
>
> Attachments: plugin.jelly
>
>
> Hi,
> I had a little problem during the creation of a war file.
> Here is an example :
> I add a applet-1.0.0.jar in the dependencies
> I don't put the applet in WEB-INF/lib so I use the property : war.target.path
> lib/
> But, this applet have a version number and I don't want to change my jsp each
> time I change the dependencies.
> I modify the plugin to add the rename of the file :
> I add a option (line 172 of plugin.jelly) :
>value="${dep.getProperty('war.target.pathfile')}"/>
>
> file="${lib.path}"/>
>
> So I can use :
> lib/applet.jar
> and now I can just change the dependencies and not the jsp file.
> Is it a wrong way or can you add this options in the plugin ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPWAR-63) ClassNotFoundException when trying to war SNAPSHOT version
[ http://jira.codehaus.org/browse/MPWAR-63?page=all ] Lukas Theussl updated MPWAR-63: --- Fix Version/s: 1.6.3 > ClassNotFoundException when trying to war SNAPSHOT version > -- > > Key: MPWAR-63 > URL: http://jira.codehaus.org/browse/MPWAR-63 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 > Environment: Fedora Core 5 > Sun JDK 1.5.0_07 > Maven 1.1-beta3 >Reporter: Steve Molloy > Fix For: 1.6.3 > > > When trying to build a war for a SNAPSHOT version, a ClassNotFoundException > occurs when trying to perform the staticInvoke on StringUtils: > ... > war:war: > [echo] Building WAR TawJni > BUILD FAILED > java.lang.ClassNotFoundException: org.apache.commons.lang.StringUtils > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.commons.jelly.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:91) > at > org.apache.commons.jelly.tags.core.InvokeStaticTag.loadClass(InvokeStaticTag.java:167) > at > org.apache.commons.jelly.tags.core.InvokeStaticTag.doTag(InvokeStaticTag.java:124) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) > at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) > at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:237) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) > at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) > at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:160) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82) > at > org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:115) > at org.apache.maven.werkz.Goal.fire(Goal.java:647) > at org.apache.maven.werkz.Goal.attain(Goal.java:582) > at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494) > at org.apache.maven.werkz.Goal.attain(Goal.java:580) > at > org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709) > at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264) > at org.apache.maven.cli.App.doMain(App.java:546) > at org.apache.maven.cli.App.main(App.java:1390) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > File.. file:/home/smolloy/.maven/cache/maven-war-plugin-1.6.2/plugin.jelly > Element... j:invokeStatic > Line.. 103 > Column 130 > org.apache.commons.lang.StringUtils > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > Total time : 2 minutes 26 seconds > Finished at : Monday, August 14, 2006 11:06:43 EDT AM -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-747) Continuum can't add a project with pom in https with authentication
[ http://jira.codehaus.org/browse/CONTINUUM-747?page=all ] Carlos Sanchez closed CONTINUUM-747. Assignee: Carlos Sanchez (was: Joakim Erdfelt) Resolution: Fixed > Continuum can't add a project with pom in https with authentication > --- > > Key: CONTINUUM-747 > URL: http://jira.codehaus.org/browse/CONTINUUM-747 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 1.1 > > Attachments: CONTINUUM-747.patch > > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > When trying to add a project with this type of url > https://username:[EMAIL PROTECTED]/foo/trunk/pom.xml > I get a 401 Unauthorized HTTP error code > Seems that the problem is in > http://svn.codehaus.org/plexus/trunk/plexus-components/plexus-formica/src/main/java/org/codehaus/plexus/formica/util/MungedHttpsURL.java > I added a test case with the right url and get that 401 too -- 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: (MSITE-45) abilitiy to create an ear/war/zip from site
[ http://jira.codehaus.org/browse/MSITE-45?page=all ] Matthew Beermann updated MSITE-45: -- Attachment: patch.txt This patch creates a new goal, site:jar, which behaves very much like javadoc:jar - packages everything up and creates an attached artifact. Note that you'll need to add plexus-archiver to the POM. > abilitiy to create an ear/war/zip from site > --- > > Key: MSITE-45 > URL: http://jira.codehaus.org/browse/MSITE-45 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Brett Porter > Attachments: patch.txt > > > I think they should be standalone goals, like in m1 > site:ear -> create ear > site:war -> create war > site:zip -> create zip > I think this one might be a lower priority. I will postpone it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-509) Ability to process scheduled builds the same as forced builds.
[ http://jira.codehaus.org/browse/CONTINUUM-509?page=comments#action_72705 ] Brill Pappin commented on CONTINUUM-509: We could really use this feature *right now (need it yesterday)* Because we only do a site build/publish build once a day, it must run even if one of the hourly builds have already updated the source. Currently we're forced to run the nightly build and deployment in a cron outside of Continuum. > Ability to process scheduled builds the same as forced builds. > -- > > Key: CONTINUUM-509 > URL: http://jira.codehaus.org/browse/CONTINUUM-509 > Project: Continuum > Issue Type: Improvement > Components: Core system >Affects Versions: 1.0.2 >Reporter: Shinobu Kawai >Priority: Minor > Fix For: 1.1 > > > It would be great if you could configure a build schedule to act like a > forced build on the scheduled build. > The use case for this is when you have two build definitions: > - One will be set to default for a forced, light build. For example, install > the artifact. > - Another will be set to a scheduled, heavy build. For example, deploy the > artifact and the project site. > If the default build is triggered, the other build will be skipped since > nothing has been updated since the forced build. And we do not want to do > heavy stuff in the default build. -- 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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_72706 ] Dennis Lundberg commented on MAVEN-1410: Let's see if I understand this correctly. If I use the latest trunk version of the pom plugin I will be able to validate a project.xml file that has groupId and artifactId but no id element. Is that correct? > pom.artifactId is missing from XML schema and pom.id should be removed > -- > > Key: MAVEN-1410 > URL: http://jira.codehaus.org/browse/MAVEN-1410 > Project: Maven > Issue Type: Bug > Components: model >Affects Versions: 1.0 >Reporter: Dennis Lundberg > Assigned To: Lukas Theussl > Fix For: 1.1-rc1 > > Attachments: maven-project-3.xsd.patch, > maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, > xdocs-artifactId.patch > > > After some discussion on the dev-list "pom.id versus pom.artifactId - which > is correct?" there seems to be some inconsistencies in the 1.0 release. > The discussion resulted in the following conclusions: > 1. The element project.id should be removed from the XML schema > 2. The element project.artifactId should be added to the XML schema > 3. Documentation needs to be updated to reflect the above issues > 1 and 2 should probably be done by one of the core developers, including > decisions regarding version numbers for the XML schema. I can make a patch > for it if you think that's ok. > I can make patches for the xdocs to fix 3. On which branch should I create > the patches? -- 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: (MSITE-45) abilitiy to create an ear/war/zip from site
[ http://jira.codehaus.org/browse/MSITE-45?page=comments#action_72708 ] Vincent Siveton commented on MSITE-45: -- Thanks Matthew! Here my comments: * adding a new dependency as plexus-archiver should be include in the patch * calling mvn clean site:jar seems to not work. Should be better that SiteJarMojo extends SiteMojo instead of AbstractSiteMojo and using super.execute() if outputDirectory doesnt exist. * please read [1] for the Maven's codestyle and how to create patch [1] http://maven.apache.org/guides/development/guide-m2-development.html > abilitiy to create an ear/war/zip from site > --- > > Key: MSITE-45 > URL: http://jira.codehaus.org/browse/MSITE-45 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Brett Porter > Attachments: patch.txt > > > I think they should be standalone goals, like in m1 > site:ear -> create ear > site:war -> create war > site:zip -> create zip > I think this one might be a lower priority. I will postpone it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1062) Upload jxls-0.8.8 bundle
Upload jxls-0.8.8 bundle Key: MAVENUPLOAD-1062 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 Project: maven-upload-requests Issue Type: Task Reporter: Leonid Vysochyn jXLS is small and easy-to-use Java library for generating Excel files using XLS templates. -- 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: (MSITE-169) links to modules where not working if a modules dir is used
[ http://jira.codehaus.org/browse/MSITE-169?page=all ] Jason Reilly updated MSITE-169: --- Attachment: MNG-MSITE-169-maven-site-plugin.patch Just fixes the url to ensure the paths match up when deployed up to the remote site. > links to modules where not working if a modules dir is used > --- > > Key: MSITE-169 > URL: http://jira.codehaus.org/browse/MSITE-169 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0, 2.0-beta-4, 2.0-beta-5 >Reporter: Mathias Brökelmann > Attachments: MNG-MSITE-169-maven-site-plugin.patch > > > I've to place the modules into a separate directory: > root/ > ..pom.xml > ..modules/ > module1 > module2 > this is supported by maven through > > modules/module1 > modules/module2 > > in pom. > but the site generation seems to be broken: > if mvn site-deploy is used the links to the modules contain > modules/module1/index.html which is ok but unfortunately the generated site > structure will be generated as follows: > root/ > ..module1 > ..module2 > The result is that the links do not work. > If I run mvn site-stage everything looks ok. The links doesn't contain > modules dir anymore and eveything is working. -- 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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_72710 ] Lukas Theussl commented on MAVEN-1410: -- That's correct. If you can confirm, I think we can close this now as I also updated the docs yesterday. > pom.artifactId is missing from XML schema and pom.id should be removed > -- > > Key: MAVEN-1410 > URL: http://jira.codehaus.org/browse/MAVEN-1410 > Project: Maven > Issue Type: Bug > Components: model >Affects Versions: 1.0 >Reporter: Dennis Lundberg > Assigned To: Lukas Theussl > Fix For: 1.1-rc1 > > Attachments: maven-project-3.xsd.patch, > maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, > xdocs-artifactId.patch > > > After some discussion on the dev-list "pom.id versus pom.artifactId - which > is correct?" there seems to be some inconsistencies in the 1.0 release. > The discussion resulted in the following conclusions: > 1. The element project.id should be removed from the XML schema > 2. The element project.artifactId should be added to the XML schema > 3. Documentation needs to be updated to reflect the above issues > 1 and 2 should probably be done by one of the core developers, including > decisions regarding version numbers for the XML schema. I can make a patch > for it if you think that's ok. > I can make patches for the xdocs to fix 3. On which branch should I create > the patches? -- 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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_72713 ]
Dennis Lundberg commented on MAVEN-1410:
Here are my findings after testing this.
First I nuked my maven-1.0.2 installation and ${user.home}/.maven
Then I installed a fresh maven-1.0.2 without upgrading anything
Tried validating the project.xml for commons-logging after adding a project
element (the long version) with namespace, as given on the validation page on
the plugin's site. It complained that the pom was missing the id element.
Installed maven-pom-plugin-1.5.1-SNAPSHOT from source
Tried validating again
{code}
BUILD FAILED
File.. C:\Documents and
Settings\dlg01\.maven\cache\maven-pom-plugin-1.5\plugin.jelly
Element... assert:assertPluginAvailable
Line.. 69
Column 42
java.lang.NullPointerException
{code}
After a while I figured out that I needed plugin-plugin-1.7. That should be
noted somewhere on the site. A better error message would be nice too...
Installed maven-plugin-plugin-1.7
Tried validating again
{code}
Using xsd file: C:\Documents and
Settings\dlg01\.maven\cache\maven-pom-plugin-1.5.1-SNAPSHOT\plugin-resources/xsd/pom-strict-3.xsd
ERROR on line 20 of file project.xml,
XPath location /project:
namespace URI of tag "project" is wrong. It must be
"http://maven.apache.org/POM/3.0.0";
G:\apache\jakarta\commons-logging\project.xml is NOT valid!
BUILD SUCCESSFUL
{code}
I double and tripple checked the project element and the url and they are the
same as the ones that are described in the validation.xml document.
I don't know if the BUILD SUCCESSFUL indicates that the validation succeded or
not.
> pom.artifactId is missing from XML schema and pom.id should be removed
> --
>
> Key: MAVEN-1410
> URL: http://jira.codehaus.org/browse/MAVEN-1410
> Project: Maven
> Issue Type: Bug
> Components: model
>Affects Versions: 1.0
>Reporter: Dennis Lundberg
> Assigned To: Lukas Theussl
> Fix For: 1.1-rc1
>
> Attachments: maven-project-3.xsd.patch,
> maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch,
> xdocs-artifactId.patch
>
>
> After some discussion on the dev-list "pom.id versus pom.artifactId - which
> is correct?" there seems to be some inconsistencies in the 1.0 release.
> The discussion resulted in the following conclusions:
> 1. The element project.id should be removed from the XML schema
> 2. The element project.artifactId should be added to the XML schema
> 3. Documentation needs to be updated to reflect the above issues
> 1 and 2 should probably be done by one of the core developers, including
> decisions regarding version numbers for the XML schema. I can make a patch
> for it if you think that's ok.
> I can make patches for the xdocs to fix 3. On which branch should I create
> the patches?
--
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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_72716 ] Lukas Theussl commented on MAVEN-1410: -- The plugin-plugin-1.7 is indicated here: http://maven.apache.org/maven-1.x/plugins/pom/goals.html. Please read http://maven.apache.org/maven-1.x/plugins/pom/validation.html (note however that's it's not up to date anymore), you still have to indicate the namespace in the project root element. BUILD SUCCESSFUL does not mean that the pom is valid, only that the validation procedure succeded. > pom.artifactId is missing from XML schema and pom.id should be removed > -- > > Key: MAVEN-1410 > URL: http://jira.codehaus.org/browse/MAVEN-1410 > Project: Maven > Issue Type: Bug > Components: model >Affects Versions: 1.0 >Reporter: Dennis Lundberg > Assigned To: Lukas Theussl > Fix For: 1.1-rc1 > > Attachments: maven-project-3.xsd.patch, > maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, > xdocs-artifactId.patch > > > After some discussion on the dev-list "pom.id versus pom.artifactId - which > is correct?" there seems to be some inconsistencies in the 1.0 release. > The discussion resulted in the following conclusions: > 1. The element project.id should be removed from the XML schema > 2. The element project.artifactId should be added to the XML schema > 3. Documentation needs to be updated to reflect the above issues > 1 and 2 should probably be done by one of the core developers, including > decisions regarding version numbers for the XML schema. I can make a patch > for it if you think that's ok. > I can make patches for the xdocs to fix 3. On which branch should I create > the patches? -- 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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_72719 ]
Dennis Lundberg commented on MAVEN-1410:
I missed the documentation on goals page for plugin-plugin, so that's OK.
G! it's time for me to go to bed now. I was validating in the wrong
directory! Too many versions of commons-logging checked out...
Validating in the *correct* directory produced this satisfactory output:
{code}
Using xsd file: C:\Documents and
Settings\dlg01\.maven\cache\maven-pom-plugin-1.5.1-SNAPSHOT\plugin-resources/xsd/pom-strict-3.xsd
G:\apache\jakarta\jakarta-commons\logging\project.xml verified: OK
BUILD SUCCESSFUL
{code}
> pom.artifactId is missing from XML schema and pom.id should be removed
> --
>
> Key: MAVEN-1410
> URL: http://jira.codehaus.org/browse/MAVEN-1410
> Project: Maven
> Issue Type: Bug
> Components: model
>Affects Versions: 1.0
>Reporter: Dennis Lundberg
> Assigned To: Lukas Theussl
> Fix For: 1.1-rc1
>
> Attachments: maven-project-3.xsd.patch,
> maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch,
> xdocs-artifactId.patch
>
>
> After some discussion on the dev-list "pom.id versus pom.artifactId - which
> is correct?" there seems to be some inconsistencies in the 1.0 release.
> The discussion resulted in the following conclusions:
> 1. The element project.id should be removed from the XML schema
> 2. The element project.artifactId should be added to the XML schema
> 3. Documentation needs to be updated to reflect the above issues
> 1 and 2 should probably be done by one of the core developers, including
> decisions regarding version numbers for the XML schema. I can make a patch
> for it if you think that's ok.
> I can make patches for the xdocs to fix 3. On which branch should I create
> the patches?
--
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-1063) Upload jpox 1.1.1 bundles
Upload jpox 1.1.1 bundles
-
Key: MAVENUPLOAD-1063
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1063
Project: maven-upload-requests
Issue Type: Task
Reporter: Joakim Erdfelt
jpox 1.1.1 artifacts + sources + javadocs.
hand assembled from official binary jars & source code (only used source code
to generate -sources.jar & -javadoc.jar optional jars)
Archive: jpox-1.1.1-combined-bundles.zip
Length Date TimeName
7056567 08-18-06 17:24 jpox-1.1.1-bundle.jar
40746 08-18-06 17:25 jpox-c3p0-1.1.1-bundle.jar
41586 08-18-06 17:25 jpox-dbcp-1.1.1-bundle.jar
651105 08-18-06 17:25 jpox-enhancer-1.1.1-bundle.jar
137935 08-18-06 17:25 jpox-java5-1.1.1-bundle.jar
1667 08-18-06 17:26 jpox-parent-1.1.1-bundle.jar
---
7929606 6 files
jpox-1.1.1-bundle.jar -
4035761 Fri Aug 18 15:32:00 EDT 2006 jpox-1.1.1-javadoc.jar
1691694 Fri Aug 18 15:32:02 EDT 2006 jpox-1.1.1-sources.jar
1780279 Fri Aug 18 12:13:32 EDT 2006 jpox-1.1.1.jar
3580 Fri Aug 18 16:19:54 EDT 2006 pom.xml
jpox-c3p0-1.1.1-bundle.jar -
35164 Fri Aug 18 15:16:52 EDT 2006 jpox-c3p0-1.1.1-javadoc.jar
2527 Fri Aug 18 15:16:52 EDT 2006 jpox-c3p0-1.1.1-sources.jar
10744 Fri Aug 18 12:16:00 EDT 2006 jpox-c3p0-1.1.1.jar
1740 Fri Aug 18 16:27:02 EDT 2006 pom.xml
jpox-dbcp-1.1.1-bundle.jar -
35233 Fri Aug 18 15:17:40 EDT 2006 jpox-dbcp-1.1.1-javadoc.jar
2750 Fri Aug 18 15:17:40 EDT 2006 jpox-dbcp-1.1.1-sources.jar
11140 Fri Aug 18 12:16:06 EDT 2006 jpox-dbcp-1.1.1.jar
2148 Fri Aug 18 16:29:32 EDT 2006 pom.xml
jpox-enhancer-1.1.1-bundle.jar -
417061 Fri Aug 18 15:18:00 EDT 2006 jpox-enhancer-1.1.1-javadoc.jar
132343 Fri Aug 18 15:18:02 EDT 2006 jpox-enhancer-1.1.1-sources.jar
166364 Fri Aug 18 12:13:32 EDT 2006 jpox-enhancer-1.1.1.jar
1994 Fri Aug 18 16:53:12 EDT 2006 pom.xml
jpox-java5-1.1.1-bundle.jar -
107728 Fri Aug 18 15:18:12 EDT 2006 jpox-java5-1.1.1-javadoc.jar
18128 Fri Aug 18 15:18:12 EDT 2006 jpox-java5-1.1.1-sources.jar
27872 Fri Aug 18 12:16:20 EDT 2006 jpox-java5-1.1.1.jar
1623 Fri Aug 18 16:55:18 EDT 2006 oldpom.xml
1566 Fri Aug 18 16:55:34 EDT 2006 pom.xml
jpox-parent-1.1.1-bundle.jar -
6328 Fri Aug 18 16:23:08 EDT 2006 pom.xml
--
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: (MAVEN-1410) pom.artifactId is missing from XML schema and pom.id should be removed
[ http://jira.codehaus.org/browse/MAVEN-1410?page=all ] Lukas Theussl closed MAVEN-1410. Resolution: Fixed > pom.artifactId is missing from XML schema and pom.id should be removed > -- > > Key: MAVEN-1410 > URL: http://jira.codehaus.org/browse/MAVEN-1410 > Project: Maven > Issue Type: Bug > Components: model >Affects Versions: 1.0 >Reporter: Dennis Lundberg > Assigned To: Lukas Theussl > Fix For: 1.1-rc1 > > Attachments: maven-project-3.xsd.patch, > maven-project.xsd-1_0-BRANCH.patch, xdocs-artifactId-version2.patch, > xdocs-artifactId.patch > > > After some discussion on the dev-list "pom.id versus pom.artifactId - which > is correct?" there seems to be some inconsistencies in the 1.0 release. > The discussion resulted in the following conclusions: > 1. The element project.id should be removed from the XML schema > 2. The element project.artifactId should be added to the XML schema > 3. Documentation needs to be updated to reflect the above issues > 1 and 2 should probably be done by one of the core developers, including > decisions regarding version numbers for the XML schema. I can make a patch > for it if you think that's ok. > I can make patches for the xdocs to fix 3. On which branch should I create > the patches? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Joakim Erdfelt updated CONTINUUM-800: - Attachment: CONTINUUM-800-maven-user-model-testing.patch Attached a new patch for maven-user-model testing. There's an odd error with UserGroup.getPermissions() that this testcase identifies, but I do not know how to fix it (yet). javax.jdo.JDODetachedFieldAccessException: You have just attempted to access field "permissions" yet this field was not detached when you detached the object. Either dont access this field, or detach the field when detaching the object. at org.apache.maven.user.model.UserGroup.jdoGetpermissions(UserGroup.java) at org.apache.maven.user.model.UserGroup.getPermissions(UserGroup.java:112) at org.apache.maven.user.model.impl.DefaultUserManagerTest.testGetSetPermissions(DefaultUserManagerTest.java:374) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-model-testing.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch, > maven-user-model-testing.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Joakim Erdfelt updated CONTINUUM-800: - Attachment: (was: maven-user-model-testing.patch) > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-model-testing.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- 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-1063) Upload jpox 1.1.1 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1063?page=comments#action_72726 ] Joakim Erdfelt commented on MAVENUPLOAD-1063: - Can also be found in expanded repo format at http://joakim.erdfelt.com/jpox-1.1.1-repo.tar.bz2 > Upload jpox 1.1.1 bundles > - > > Key: MAVENUPLOAD-1063 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1063 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joakim Erdfelt > > jpox 1.1.1 artifacts + sources + javadocs. > hand assembled from official binary jars & source code (only used source code > to generate -sources.jar & -javadoc.jar optional jars) > Archive: jpox-1.1.1-combined-bundles.zip > Length Date TimeName > > 7056567 08-18-06 17:24 jpox-1.1.1-bundle.jar > 40746 08-18-06 17:25 jpox-c3p0-1.1.1-bundle.jar > 41586 08-18-06 17:25 jpox-dbcp-1.1.1-bundle.jar >651105 08-18-06 17:25 jpox-enhancer-1.1.1-bundle.jar >137935 08-18-06 17:25 jpox-java5-1.1.1-bundle.jar > 1667 08-18-06 17:26 jpox-parent-1.1.1-bundle.jar > --- > 7929606 6 files > jpox-1.1.1-bundle.jar - > 4035761 Fri Aug 18 15:32:00 EDT 2006 jpox-1.1.1-javadoc.jar > 1691694 Fri Aug 18 15:32:02 EDT 2006 jpox-1.1.1-sources.jar > 1780279 Fri Aug 18 12:13:32 EDT 2006 jpox-1.1.1.jar > 3580 Fri Aug 18 16:19:54 EDT 2006 pom.xml > jpox-c3p0-1.1.1-bundle.jar - > 35164 Fri Aug 18 15:16:52 EDT 2006 jpox-c3p0-1.1.1-javadoc.jar > 2527 Fri Aug 18 15:16:52 EDT 2006 jpox-c3p0-1.1.1-sources.jar > 10744 Fri Aug 18 12:16:00 EDT 2006 jpox-c3p0-1.1.1.jar > 1740 Fri Aug 18 16:27:02 EDT 2006 pom.xml > jpox-dbcp-1.1.1-bundle.jar - > 35233 Fri Aug 18 15:17:40 EDT 2006 jpox-dbcp-1.1.1-javadoc.jar > 2750 Fri Aug 18 15:17:40 EDT 2006 jpox-dbcp-1.1.1-sources.jar > 11140 Fri Aug 18 12:16:06 EDT 2006 jpox-dbcp-1.1.1.jar > 2148 Fri Aug 18 16:29:32 EDT 2006 pom.xml > jpox-enhancer-1.1.1-bundle.jar - > 417061 Fri Aug 18 15:18:00 EDT 2006 jpox-enhancer-1.1.1-javadoc.jar > 132343 Fri Aug 18 15:18:02 EDT 2006 jpox-enhancer-1.1.1-sources.jar > 166364 Fri Aug 18 12:13:32 EDT 2006 jpox-enhancer-1.1.1.jar > 1994 Fri Aug 18 16:53:12 EDT 2006 pom.xml > jpox-java5-1.1.1-bundle.jar - > 107728 Fri Aug 18 15:18:12 EDT 2006 jpox-java5-1.1.1-javadoc.jar > 18128 Fri Aug 18 15:18:12 EDT 2006 jpox-java5-1.1.1-sources.jar > 27872 Fri Aug 18 12:16:20 EDT 2006 jpox-java5-1.1.1.jar > 1623 Fri Aug 18 16:55:18 EDT 2006 oldpom.xml > 1566 Fri Aug 18 16:55:34 EDT 2006 pom.xml > jpox-parent-1.1.1-bundle.jar - > 6328 Fri Aug 18 16:23:08 EDT 2006 pom.xml -- 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-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=comments#action_72727 ] Carlos Sanchez commented on CONTINUUM-800: -- Applied latest patch > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-model-testing.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- 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-1063) Upload jpox 1.1.1 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1063?page=all ] Carlos Sanchez closed MAVENUPLOAD-1063. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload jpox 1.1.1 bundles > - > > Key: MAVENUPLOAD-1063 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1063 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joakim Erdfelt > Assigned To: Carlos Sanchez > > jpox 1.1.1 artifacts + sources + javadocs. > hand assembled from official binary jars & source code (only used source code > to generate -sources.jar & -javadoc.jar optional jars) > Archive: jpox-1.1.1-combined-bundles.zip > Length Date TimeName > > 7056567 08-18-06 17:24 jpox-1.1.1-bundle.jar > 40746 08-18-06 17:25 jpox-c3p0-1.1.1-bundle.jar > 41586 08-18-06 17:25 jpox-dbcp-1.1.1-bundle.jar >651105 08-18-06 17:25 jpox-enhancer-1.1.1-bundle.jar >137935 08-18-06 17:25 jpox-java5-1.1.1-bundle.jar > 1667 08-18-06 17:26 jpox-parent-1.1.1-bundle.jar > --- > 7929606 6 files > jpox-1.1.1-bundle.jar - > 4035761 Fri Aug 18 15:32:00 EDT 2006 jpox-1.1.1-javadoc.jar > 1691694 Fri Aug 18 15:32:02 EDT 2006 jpox-1.1.1-sources.jar > 1780279 Fri Aug 18 12:13:32 EDT 2006 jpox-1.1.1.jar > 3580 Fri Aug 18 16:19:54 EDT 2006 pom.xml > jpox-c3p0-1.1.1-bundle.jar - > 35164 Fri Aug 18 15:16:52 EDT 2006 jpox-c3p0-1.1.1-javadoc.jar > 2527 Fri Aug 18 15:16:52 EDT 2006 jpox-c3p0-1.1.1-sources.jar > 10744 Fri Aug 18 12:16:00 EDT 2006 jpox-c3p0-1.1.1.jar > 1740 Fri Aug 18 16:27:02 EDT 2006 pom.xml > jpox-dbcp-1.1.1-bundle.jar - > 35233 Fri Aug 18 15:17:40 EDT 2006 jpox-dbcp-1.1.1-javadoc.jar > 2750 Fri Aug 18 15:17:40 EDT 2006 jpox-dbcp-1.1.1-sources.jar > 11140 Fri Aug 18 12:16:06 EDT 2006 jpox-dbcp-1.1.1.jar > 2148 Fri Aug 18 16:29:32 EDT 2006 pom.xml > jpox-enhancer-1.1.1-bundle.jar - > 417061 Fri Aug 18 15:18:00 EDT 2006 jpox-enhancer-1.1.1-javadoc.jar > 132343 Fri Aug 18 15:18:02 EDT 2006 jpox-enhancer-1.1.1-sources.jar > 166364 Fri Aug 18 12:13:32 EDT 2006 jpox-enhancer-1.1.1.jar > 1994 Fri Aug 18 16:53:12 EDT 2006 pom.xml > jpox-java5-1.1.1-bundle.jar - > 107728 Fri Aug 18 15:18:12 EDT 2006 jpox-java5-1.1.1-javadoc.jar > 18128 Fri Aug 18 15:18:12 EDT 2006 jpox-java5-1.1.1-sources.jar > 27872 Fri Aug 18 12:16:20 EDT 2006 jpox-java5-1.1.1.jar > 1623 Fri Aug 18 16:55:18 EDT 2006 oldpom.xml > 1566 Fri Aug 18 16:55:34 EDT 2006 pom.xml > jpox-parent-1.1.1-bundle.jar - > 6328 Fri Aug 18 16:23:08 EDT 2006 pom.xml -- 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-1062) Upload jxls-0.8.8 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1062?page=comments#action_72728 ] Carlos Sanchez commented on MAVENUPLOAD-1062: - you must proof ownership of jxls.org to use that groupid > Upload jxls-0.8.8 bundle > > > Key: MAVENUPLOAD-1062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 > Project: maven-upload-requests > Issue Type: Task >Reporter: Leonid Vysochyn > > jXLS is small and easy-to-use Java library for generating Excel files using > XLS templates. -- 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-1055) Please Upload Registry J2SE
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1055?page=comments#action_72729 ] Carlos Sanchez commented on MAVENUPLOAD-1055: - you must remove the entry > Please Upload Registry J2SE > --- > > Key: MAVENUPLOAD-1055 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1055 > Project: maven-upload-requests > Issue Type: Task >Reporter: Shane Isbell > > This library provides a registry function for storing and finding data. It > supports Hibernate2, Hibernate3 and JAXB configuration files. -- 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-1059) j2ssh (sshtools) 0.2.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1059?page=comments#action_72730 ] Carlos Sanchez commented on MAVENUPLOAD-1059: - read the instructions > j2ssh (sshtools) 0.2.7 > -- > > Key: MAVENUPLOAD-1059 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1059 > Project: maven-upload-requests > Issue Type: Task >Reporter: Michael Burton > > update to j2ssh. Built from > http://prdownloads.sourceforge.net/sshtools/j2ssh-0.2.7-src.tar.gz > SSHTools is a suite of Java SSH applications providing a Java SSH API, SSH > Terminal, SSH secured VNC client, SFTP client and SSH Daemon. -- 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-435) Incorrect POM for xdoclet-bea-module.
[ http://jira.codehaus.org/browse/MEV-435?page=comments#action_72731 ] Carlos Sanchez commented on MEV-435: http://www.ibiblio.org/maven2/xdoclet/xdoclet-bea-module/1.2.3/xdoclet-bea-module-1.2.3.pom > Incorrect POM for xdoclet-bea-module. > - > > Key: MEV-435 > URL: http://jira.codehaus.org/browse/MEV-435 > Project: Maven Evangelism > Issue Type: Improvement >Reporter: Davy Toch > > The POM should also include a dependency to xdoclet-web-module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MEV-435) Incorrect POM for xdoclet-bea-module.
[ http://jira.codehaus.org/browse/MEV-435?page=all ] Carlos Sanchez moved MAVENUPLOAD-1058 to MEV-435: - Bundle URL: (was: http://www.ibiblio.org/maven2/xdoclet/xdoclet-bea-module/1.2.3/xdoclet-bea-module-1.2.3.pom) Workflow: jira (was: Maven New) Key: MEV-435 (was: MAVENUPLOAD-1058) Project: Maven Evangelism (was: maven-upload-requests) > Incorrect POM for xdoclet-bea-module. > - > > Key: MEV-435 > URL: http://jira.codehaus.org/browse/MEV-435 > Project: Maven Evangelism > Issue Type: Improvement >Reporter: Davy Toch > > The POM should also include a dependency to xdoclet-web-module. -- 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-1047) Upload Retroweaver 1.2.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1047?page=comments#action_72732 ] Carlos Sanchez commented on MAVENUPLOAD-1047: - 404 not found error > Upload Retroweaver 1.2.4 > > > Key: MAVENUPLOAD-1047 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1047 > Project: maven-upload-requests > Issue Type: Task >Reporter: Xavier Le Vourch > > Retroweaver is a tool, which converts Java 5 (or 6) compliant > class files into Java 1.x compliant class files. The jar file > retroweaver.jar contains both the class processor (which may > be used at compile time) and the runtime classes. Additionally > there is the jar file retroweaver-rt.jar (which contains the > runtime classes only). > The bundle contains file for both the retroweaver and retroweaver-rt > subpackages. -- 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-1061) Upload qdox 1.6 on m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1061?page=comments#action_72733 ] Carlos Sanchez commented on MAVENUPLOAD-1061: - can you provide a pom with the minimal info, like license, url,... > Upload qdox 1.6 on m2 repo > -- > > Key: MAVENUPLOAD-1061 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1061 > Project: maven-upload-requests > Issue Type: Task >Reporter: Guillaume Nodet > -- 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-1062) Upload jxls-0.8.8 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1062?page=comments#action_72734 ] Leonid Vysochyn commented on MAVENUPLOAD-1062: -- How should I prove it? I am the foundator of this project and have plans to use jxls.org domain for this project in the future. Currently the project is hosted on sourceforge.net site. You can make sure that I am the administrator and main developer of this project. > Upload jxls-0.8.8 bundle > > > Key: MAVENUPLOAD-1062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 > Project: maven-upload-requests > Issue Type: Task >Reporter: Leonid Vysochyn > > jXLS is small and easy-to-use Java library for generating Excel files using > XLS templates. -- 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-1062) Upload jxls-0.8.8 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1062?page=comments#action_72735 ] Leonid Vysochyn commented on MAVENUPLOAD-1062: -- Also you can take a look at the package structure of jXLS. All packages start from org.jxls. > Upload jxls-0.8.8 bundle > > > Key: MAVENUPLOAD-1062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 > Project: maven-upload-requests > Issue Type: Task >Reporter: Leonid Vysochyn > > jXLS is small and easy-to-use Java library for generating Excel files using > XLS templates. -- 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-1062) Upload jxls-0.8.8 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1062?page=comments#action_72736 ] Leonid Vysochyn commented on MAVENUPLOAD-1062: -- Does it mean that you can't upload this library until groupId is changed to something like net.sf.jxls? > Upload jxls-0.8.8 bundle > > > Key: MAVENUPLOAD-1062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 > Project: maven-upload-requests > Issue Type: Task >Reporter: Leonid Vysochyn > > jXLS is small and easy-to-use Java library for generating Excel files using > XLS templates. -- 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-1062) Upload jxls-0.8.8 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1062?page=comments#action_72737 ] Joakim Erdfelt commented on MAVENUPLOAD-1062: - Proof is just to put the bundle up on www.jxls.org for download. However, if you change it to net.sf.jxls now, you can change it to org.jxls later and include a relocation section in the pom to notify users that the groupId has changed. It's quite common. See example with "servletApi" -> "javax.servlet" found here - http://www.ibiblio.org/maven2/servletapi/servlet-api/2.4-20040521/servlet-api-2.4-20040521.pom 4.0.0 servletapi servlet-api 2.4-20040521 javax.servlet servlet-api > Upload jxls-0.8.8 bundle > > > Key: MAVENUPLOAD-1062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 > Project: maven-upload-requests > Issue Type: Task >Reporter: Leonid Vysochyn > > jXLS is small and easy-to-use Java library for generating Excel files using > XLS templates. -- 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-1059) j2ssh (sshtools) 0.2.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1059?page=comments#action_72738 ] Michael Burton commented on MAVENUPLOAD-1059: - I read the instructions, but clearly you think I must have missed something. Please tell me what I missed so I can correct it and I will be happy to do so. > j2ssh (sshtools) 0.2.7 > -- > > Key: MAVENUPLOAD-1059 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1059 > Project: maven-upload-requests > Issue Type: Task >Reporter: Michael Burton > > update to j2ssh. Built from > http://prdownloads.sourceforge.net/sshtools/j2ssh-0.2.7-src.tar.gz > SSHTools is a suite of Java SSH applications providing a Java SSH API, SSH > Terminal, SSH secured VNC client, SFTP client and SSH Daemon. -- 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: (MSITE-138) site:stage does not create xref
[ http://jira.codehaus.org/browse/MSITE-138?page=comments#action_72739 ] MTStorm commented on MSITE-138: --- Is there realy no update yet? This is realy a nasty showstopper. > site:stage does not create xref > --- > > Key: MSITE-138 > URL: http://jira.codehaus.org/browse/MSITE-138 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jorg Heymans > > as reported here : > http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/40178 > the xref and test-xref dirs both have an empty index.html after the site is > staged. -- 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: (MSITE-138) site:stage does not create xref
[ http://jira.codehaus.org/browse/MSITE-138?page=comments#action_72741 ] Vincent Siveton commented on MSITE-138: --- In my point of view, it doesnt seem very hard: we need to setReportOutputDirectory in SiteRunMojo, and to update external plugins to handle that. > site:stage does not create xref > --- > > Key: MSITE-138 > URL: http://jira.codehaus.org/browse/MSITE-138 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jorg Heymans > Assigned To: Vincent Siveton > > as reported here : > http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/40178 > the xref and test-xref dirs both have an empty index.html after the site is > staged. -- 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-822) Create acegi acl tables on database creation
[ http://jira.codehaus.org/browse/CONTINUUM-822?page=comments#action_72742 ] Carlos Sanchez commented on CONTINUUM-822: -- applied patch, i'll be working on getting this running in the webapp the first time the db is created > Create acegi acl tables on database creation > > > Key: CONTINUUM-822 > URL: http://jira.codehaus.org/browse/CONTINUUM-822 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-822.patch > > > The SQL script is in continuum-security-acegi > src/main/resources > org.apache.maven.continuum.security.acegi.acl.acegi-acl-derby.sql > This needs to be run against the db when the database is created. I think > there's a sql plugin for maven somewhere. -- 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-61) Document how to set manifest classpath and exclude dependency from WEB-INF/lib
[ http://jira.codehaus.org/browse/MWAR-61?page=comments#action_72743 ] Michael Case commented on MWAR-61: -- I followed these directions exactly and I still ended up with the dependencies in my WEB-INF/lib. The following is the relevant portion of my POM file. org.codehaus.xfire xfire-all 1.1.1 true org.springframework spring 1.2.8 true junit junit 3.8.1 test org.apache.maven.plugins maven-war-plugin 2.0.1 true > Document how to set manifest classpath and exclude dependency from WEB-INF/lib > -- > > Key: MWAR-61 > URL: http://jira.codehaus.org/browse/MWAR-61 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: David Jencks > Assigned To: Brett Porter > Fix For: 2.0.2 > > Attachments: war-plugin-manifestcp-doc.patch > > > I had to get some help from evenisse to figure out how to generate the > manifest classpath yet not include all the dependencies in WEB-INF/lib. I > still don't know how to get a dependency into WEB-INF/lib but not the > manifest classpath when generating the manifest classpath, but this should > help anyone just trying to use a manifest cp in an ear. -- 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-1062) Upload jxls-0.8.8 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1062?page=comments#action_72748 ] Leonid Vysochyn commented on MAVENUPLOAD-1062: -- I have changed groupId to net.sf.jxls . Please take a look and let me know if there are any other issues. > Upload jxls-0.8.8 bundle > > > Key: MAVENUPLOAD-1062 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1062 > Project: maven-upload-requests > Issue Type: Task >Reporter: Leonid Vysochyn > > jXLS is small and easy-to-use Java library for generating Excel files using > XLS templates. -- 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
