[jira] Commented: (DOXIA-79) Doxia generates different XHTML for the same xdoc code
[ http://jira.codehaus.org/browse/DOXIA-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85970 ] Stefan Broetz commented on DOXIA-79: Henning, I was able to workaround this issue by modifying the xdoc list items in the following way: ul li pBla bla bla/p /li /ul Note the additional paragraph tag around each list item content. This may or may not work with HEAD, but it seems to work for Maven 2.0.4 and its dependencies (at least for me...) Doxia generates different XHTML for the same xdoc code -- Key: DOXIA-79 URL: http://jira.codehaus.org/browse/DOXIA-79 Project: doxia Issue Type: Bug Components: Core Affects Versions: 1.0-alpha-8, 1.0 Reporter: Henning Schmiedehausen Assigned To: Vincent Siveton Fix For: 1.0 Consider the following xdoc code: section name=1 subsection name=s1 pp1/p ul lil1/li /ul /subsection subsection name=s2 pp2/p ul lil1/li /ul /subsection /section This renders to the following XHTML code: a name=1/adiv class=sectionh21/h2 a name=s1/adiv class=sectionh3s1/h3 pp1/p ullil1/li/ul /div a name=s2/adiv class=sectionh3s2/h3 p2 ullil1/li/ul /div /div Please not the missing p /p around 'p2'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2676) maven-dependency-analyser shared component plugin
[ http://jira.codehaus.org/browse/MNG-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85973 ] Joerg Schaible commented on MNG-2676: - Hi Mark, looks great! A real help to identify the used deps. Biggest problem though are the indirect deps that are simply discovered since they implement some kind of interface as it is supported by the SPI spec of the JDK or dependency injection frameworks like PicoContainer or Spring. But I guess there's always room for improvement. The analyser may have a SPI on its own for different implementations identifying indirect deps by looking for META-INF/services or grokking the Spring config. All of this should be integrated into the dependencies plugin though, but I think you had that in mind anyway. - Jörg BTW: The analyser does not compile/run with JDK 1.4: $ diff maven-dependency-analyser/src/main/java/org/apache/maven/shared/dependency/analyser/ClassFileVisitorUtils.java maven-dependency-analyser.14/src/main/java/org/apache/maven/shared/dependency/analyser/ClassFileVisitorUtils.java 22a23 import java.net.URI; 60c61 File file = new File( url.toURI().getPath() ); --- File file = new File( new URI( url.toString() ).getPath() ); 73c74 throw new IllegalArgumentException( Cannot accept visitor on URL: + url, exception ); --- throw ( IllegalArgumentException )( new IllegalArgumentException( Cannot accept visitor on URL: + url ).initCause( exception ) ); maven-dependency-analyser shared component plugin --- Key: MNG-2676 URL: http://jira.codehaus.org/browse/MNG-2676 Project: Maven 2 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.4 Reporter: Mark Hobson Assigned To: Joakim Erdfelt Attachments: maven-dependency-analyser-plugin.zip, maven-dependency-analyser.zip A shared component and plugin to analyse project dependencies as described in the thread: http://www.mail-archive.com/dev@maven.apache.org/msg61432.html Javadoc and tests to come when I get some more free time ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-179) Assembled jar includes artifact names in path
[
http://jira.codehaus.org/browse/MASSEMBLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85972
]
Milos Volauf commented on MASSEMBLY-179:
I found this issue too.
Workaround:
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
!-- use this empty name if using maven-assembly-plugin 2.2-SNAPSHOT,
otherwise the artifacts are unpacked into unwanted subfolders
--
outputFileNameMapping/
scoperuntime/scope
/dependencySet
Assembled jar includes artifact names in path
-
Key: MASSEMBLY-179
URL: http://jira.codehaus.org/browse/MASSEMBLY-179
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Jonathan Komorek
Priority: Critical
This issue does not occur in 2.1 and began occurring in 2.2-SNAPSHOT
(roughly) a couple months ago.
After assembling a jar, the path for each of the included files begins with
what seems to be ${artifactId}-${version}.${packaging}
This includes files from dependent jars and files from sub-modules - all
files.
The plugin is configured in the POM as follows:
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
executions
execution
id1/id
phasepackage/phase
goals
goalattached/goal
/goals
/execution
/executions
version2.2-SNAPSHOT/version
configuration
descriptorassembly.xml/descriptor
/configuration
/plugin
/plugins
/build
The entire assembly.xml is as follows:
assembly
iddependencies/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
scoperuntime/scope
/dependencySet
/dependencySets
/assembly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-180) A bug in artifact filtering ( maven-common-artifact-filters )
A bug in artifact filtering ( maven-common-artifact-filters ) - Key: MASSEMBLY-180 URL: http://jira.codehaus.org/browse/MASSEMBLY-180 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Milos Volauf I found this bug while using includes and excludes section in dependencySet element. I had to check the source code to understand the Advanced Artifact-Matching in includes and excludes. I found a bug in the project maven-common-artifact-filters, 1.0-alpha-1. I checked the class PatternIncludesArtifactFilter, revision 487820. There is a bug in the method: private boolean matchAgainst( String value, List patterns, boolean regionMatch ) There is an iteration of a list of patterns. When a pattern matches, the method should return true. When no pattern matches, it should return false. However, when there is a pattern using a wildcard (*) and this pattern does not match, the flow will reach the line 216 where the method returns false. Gotcha! the next patterns are not tried In other words, say we have : dependencySet ... exclusions exclusion*:jar:*/exclusion /exclusion*:test-jar:*/exclusion /exclusions ... /dependencySet The effect of the bug is that the seconds pattern (*:test-jar:*) will not be used, because if matching of the first (*:jar:*) fails, the method returns false, the next patterns is not used. I hope I clarified this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated MNG-2722:
---
Attachment: embedder-start-twice.patch
This fix causes all kinds of problems in various Maven plugins if you have to
change the settings, for example, by calling start() a second time with a
different settings.xml file (setUserSettingsFile() and setGlobalSettingsFile())
because some parts of Maven don't copy the new values.
In the attached test case, you'll find a couple of bugs:
- The embedder crashes horribly if you change the localRepository path to an
empty directory (see stacktrace in the test case).
- The path to the repository is correct in the embedder but not in the
execution request if the second settings file specifies localRepository
My guess is that this causes all kinds of strange bugs and behaviors in the
plugins which are then loaded.
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-1341) Upload rat-lib-0.4.1
Upload rat-lib-0.4.1 Key: MAVENUPLOAD-1341 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1341 Project: maven-upload-requests Issue Type: Task Reporter: Jochen Wiedmann Public release of RAT, the Release Audit Tool -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-675) Add Working Copy to the Legends
[ http://jira.codehaus.org/browse/CONTINUUM-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-675. -- Assignee: Emmanuel Venisse Resolution: Fixed Applied. Thanks. Add Working Copy to the Legends --- Key: CONTINUUM-675 URL: http://jira.codehaus.org/browse/CONTINUUM-675 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.0.3 Reporter: Shinobu Kawai Assigned To: Emmanuel Venisse Priority: Trivial Fix For: 1.1 Attachments: [CONTINUUM-675]-continuum-webapp.patch, legendbg.gif Add Working Copy to the Legends on the left -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1143) user with only 'project user' role can start a project-level build
[ http://jira.codehaus.org/browse/CONTINUUM-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1143. --- Assignee: Emmanuel Venisse (was: Teodoro Cue Jr.) Resolution: Fixed Fix Version/s: 1.1 Applied. Thanks. user with only 'project user' role can start a project-level build -- Key: CONTINUUM-1143 URL: http://jira.codehaus.org/browse/CONTINUUM-1143 Project: Continuum Issue Type: Bug Components: Security Affects Versions: 1.1 Reporter: Wendy Smoak Assigned To: Emmanuel Venisse Priority: Critical Fix For: 1.1 Attachments: CONTINUUM-1143-continuum-webapp.patch The 'build now' icon for a project-level build is enabled for users without the developer role. See: http://people.apache.org/~wsmoak/maven/continuum/continuum-project-user-role-can-build.jpg Here, the guest user has been given the 'project user' role and should not be able to start any builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85989
]
Aaron Digulla commented on MNG-2722:
After some more tests, my patch doesn't seem the fix the localRepository
problem.
localRepository is only read when it is specified in ~/.m2/settings.xml. If it
is specified in the file specified with setGlobalSettingsFile(), it's ignored.
It also doesn't fix the issue MNGECLIPSE-231 as I had hoped :-(
All I can say is that defaultsPopulator doesn't fill in the correct local
repository when it is called in MavenEmbedder.
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1147) Even if a user doesn't show a group in the group summary (because he doesn't have roles), he can access to the project group page and all other sub pages if he knows t
Even if a user doesn't show a group in the group summary (because he doesn't have roles), he can access to the project group page and all other sub pages if he knows the url - Key: CONTINUUM-1147 URL: http://jira.codehaus.org/browse/CONTINUUM-1147 Project: Continuum Issue Type: Bug Components: Security Reporter: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (CONTINUUM-1147) Even if a user doesn't show a group in the group summary (because he doesn't have roles), he can access to the project group page and all other sub pages if he kn
[ http://jira.codehaus.org/browse/CONTINUUM-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CONTINUUM-1147 started by Maria Odea Ching. Even if a user doesn't show a group in the group summary (because he doesn't have roles), he can access to the project group page and all other sub pages if he knows the url - Key: CONTINUUM-1147 URL: http://jira.codehaus.org/browse/CONTINUUM-1147 Project: Continuum Issue Type: Bug Components: Security Reporter: Maria Odea Ching Assigned To: Maria Odea Ching -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1310) NanoXML Lite
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85996 ] Tassilo Schweyer commented on MAVENUPLOAD-1310: --- now it is(ok had to use fake entries in scm-url and scm-connection) NanoXML Lite Key: MAVENUPLOAD-1310 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1310 Project: maven-upload-requests Issue Type: Task Reporter: Tassilo Schweyer NanoXML Lite is an extremely small (6KB) XML parser -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-262) Surefire report plugins fails with OutOfMemoryError, doesn't scale
[
http://jira.codehaus.org/browse/SUREFIRE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85997
]
Martin Probst commented on SUREFIRE-262:
Additionally, when you manage to reduce the reports size so that
surefire-report manages to create a report, it creates one single big HTML
file. The file for my 2200 tests (104 errors w/ stack traces) is 66 MB in size.
This is not viewable in todays browsers.
Only solution would probably be an (optional?) multi-file report. Should I file
another bug for that?
Surefire report plugins fails with OutOfMemoryError, doesn't scale
--
Key: SUREFIRE-262
URL: http://jira.codehaus.org/browse/SUREFIRE-262
Project: Maven Surefire
Issue Type: Bug
Components: report plugin
Affects Versions: 2.0 Report Plugin
Environment: MacOS X; java version 1.5.0_06
Reporter: Martin Probst
Fix For: 2.3
The surefire report plugin fails to create a test report with an
OutOfMemoryError.
I've set MAVEN_OPTS to -Xmx512m and to -Xmx1024m. With 512m the report fails
after about 3 minutes, with 1GB it taks significantly longer. Both report
generation tasks fail.
{pre}
[INFO] [surefire-report:report]
[WARNING] Unable to locate Test Source XRef to link to - DISABLED
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Java heap space
[INFO]
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
[INFO]
[INFO] Total time: 2 minutes 21 seconds
[INFO] Finished at: Sat Jan 20 12:59:13 CET 2007
[INFO] Final Memory: 69M/1016M
[INFO]
{/pre}
This happens regardless of the actual JUnit tests - I ran this with
-Dmaven.test.skip=true.
The target/surefire-reports directory contains over 700 MB of XML reports,
mainly due to long stack traces in the mostly failing 2000+ tests. However
the JUnit reports plugin in ANT which we used to use had no problems handling
this kind of data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJXR-21) Jxr plugin fails if xdoclet executed without sources generation
Jxr plugin fails if xdoclet executed without sources generation --- Key: MJXR-21 URL: http://jira.codehaus.org/browse/MJXR-21 Project: Maven 2.x JXR Plugin Issue Type: Bug Reporter: Fernando Lindner Priority: Critical JXR plugin always tries to find directory target/generated-sources/xdoclet if a xdoclet execution is set. For instance, if a webdoclet task is used, no target/generated-sources/xdoclet directory should be created, resulting in a build error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MJXR-21) Jxr plugin fails if xdoclet executed without sources generation
[ http://jira.codehaus.org/browse/MJXR-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85999 ] Fernando Lindner commented on MJXR-21: -- error log for mvn site execution, using a webdoclet task: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Error while generating the HTML source code of the projet. basedir C:\projects\myProject\web\target\generated-sources\xdoclet does not exist Jxr plugin fails if xdoclet executed without sources generation --- Key: MJXR-21 URL: http://jira.codehaus.org/browse/MJXR-21 Project: Maven 2.x JXR Plugin Issue Type: Bug Reporter: Fernando Lindner Priority: Critical JXR plugin always tries to find directory target/generated-sources/xdoclet if a xdoclet execution is set. For instance, if a webdoclet task is used, no target/generated-sources/xdoclet directory should be created, resulting in a build error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2793) Snapshot plugins cannot be resolved correctly with java6
Snapshot plugins cannot be resolved correctly with java6 Key: MNG-2793 URL: http://jira.codehaus.org/browse/MNG-2793 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Dependencies Affects Versions: 2.0.4 Reporter: Daniel Kulp Attachments: maven-artifact-manager.patch With java 6, builds that use snapshot repositories are consistently failing if the snapshots are not available in the local repository. The error is something like: [INFO] [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: org.apache.maven:maven-parent:pom:1 from the repository. [DEBUG] maven-install-plugin: using locally installed snapshot [DEBUG] maven-install-plugin: resolved to version 2.2-SNAPSHOT from repository central [DEBUG] Skipping disabled repository central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-install-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-install-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-install-plugin:pom:2.2-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2) If the artifacts are first downloaded by building with JDK 1.5, everything works fine. After investigating, the problem is in the transforms that the maven-artifact-manager. With JDK 1.5, the order they run is: org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation org.apache.maven.artifact.transform.SnapshotTransformation but with Java 6, for some reason, the order is: org.apache.maven.artifact.transform.SnapshotTransformation org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation The LatestArtifactTransform is what uses to the metadata to determine the actual version number (for the install plugin, 2.2-SNAPSHOT). The SnapshotTransform then converts that to 2.2-20061118.060401-2 which is what is then downloaded. However, in the java 6 case, the SnapshotTransform is run first and since the version is not a SNAPSHOT version number, it doesn't do any processing so then the downloading ends up looking for 2.2-SNAPSHOT, not the full version, which then fails. I chatted with brett_ on IRC about this: [09:46:35] dkulp OK. I'm trying to track down why my builds are failing with JDK 1.6 [09:46:53] dkulp The issue is the transforms are in a different order with 1.6 than 1.5 [09:47:17] brett_ yikes [09:47:42] dkulp With 1.5, its Latest/Release/Snapshot. [09:47:46] brett_ not sure why that would matter. But I guess sorting the transforms consistently would help. [09:47:50] dkulp With 1.6, it's Snapshot/Latest/Release [09:48:06] brett_ ok, fairly simple to fix in Maven. [09:48:10] dkulp The Latest needs to be before Snapshot. [09:49:08] dkulp I tried changing the order of things in the components.xml. Didn't seem to change anything. But this is plexus stuff which I don't know anything about. [09:49:22] brett_ hmm, it should be populated as a list [09:49:28] brett_ but maybe the list is backed by a map [09:49:35] dkulp Yep. Verified it's and ArrayList [09:49:51] brett_ s/backed/populated by/ [09:50:48] dkulp That would definitely do it. [09:51:21] dkulp Any hints on where to look? [09:51:48] brett_ oh, I would go into plexus [09:51:52] dkulp (or how to debug)? [09:51:58] brett_ sorry, wouldn't [09:52:13] brett_ it's changing too much [09:52:18] brett_ 2.0.5 will be stuck with alpha-10 [09:52:24] brett_ so, need to work around it in Maven [09:53:00] brett_ perhaps just hack the order in the code, and then fix plexus to honour the order in components.xml in trunk [09:54:57] dkulp Hmm..ok.Is there something plexus will call after setting the List field so I can resort it? [09:55:30] dkulp Or will adding a setArtifactTransformations(List) work? [09:55:40] dkulp (again, not familiar with plexus) [09:56:25] brett_ no, it sets it using private field injection [09:57:04] dkulp No optional init methods or
[jira] Commented: (MNG-2792) When Maven runs Java 6, maven-metadata.xml file is corrupted
[ http://jira.codehaus.org/browse/MNG-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86001 ] Matthew Beermann commented on MNG-2792: --- Daniel Kulp adds: No. It's really not corrupted despite the error. I've been tracing through the maven code and there are a series of transforms (not xml transforms) that an artifact goes through to be resolved. With Java 5, the order is: org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation org.apache.maven.artifact.transform.SnapshotTransformation but with Java 6, for some reason, the order is: org.apache.maven.artifact.transform.SnapshotTransformation org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation The LatestArtifactTransform is what uses to the metadata to determine the actual version number (for the install plugin, 2.2-SNAPSHOT). The SnapshotTransform then converts that to 2.2-20061118.060401-2 which is what is then downloaded. However, in the java 6 case, the SnapshotTransform is run first and since the version is not a SNAPSHOT version number, it doesn't do any processing so then the downloading ends up looking for 2.2-SNAPSHOT, not the full version, which then fails. I'm not sure why the order of the transforms is different yet. Dan When Maven runs Java 6, maven-metadata.xml file is corrupted -- Key: MNG-2792 URL: http://jira.codehaus.org/browse/MNG-2792 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Matthew Beermann Priority: Critical Attachments: maven-metadata.xml When you run Maven under Java 6, the maven-metadata.xml file that gets written to the remote repository is markedly different from the one generated under Java 5 and earlier. This file is corrupted in the sense that Maven reports errors about it, and might not be able to locate snapshots as a result. See attachment for an example file; you'd expect to see build numbers or -SNAPSHOTs, but not both at once. This issue is described further at http://www.nabble.com/Maven-and-JDK-1.6-t3060866s177.html (originally message only, not the followups). This might be related to MNG-2709, but I don't think it's a duplicate, as it has nothing to do with testing or parents. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MAVENUPLOAD-1337) Upload of latest Findbugs (v. 1.1.3) artifacts to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Christiansen updated MAVENUPLOAD-1337: -- Attachment: findbugs113.jar Here's the jar uploaded to JIRA Upload of latest Findbugs (v. 1.1.3) artifacts to ibiblio - Key: MAVENUPLOAD-1337 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1337 Project: maven-upload-requests Issue Type: Task Reporter: Jon Christiansen Attachments: findbugs113.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1340) Upload hibernate-tools 3.2.0-beta9a
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86003 ] Johann Reyes commented on MAVENUPLOAD-1340: --- Added missing license and scm entry in jtidy pom Upload hibernate-tools 3.2.0-beta9a --- Key: MAVENUPLOAD-1340 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1340 Project: maven-upload-requests Issue Type: Task Reporter: Johann Reyes http://hiberforum.org/hibernate-tools-3.2.0.beta9a-bundle.jar http://hiberforum.org/jtidy-r8-20060801-bundle.jar http://tools.hibernate.org Please upload new version of hibernate-tools + updated dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2793) Snapshot plugins cannot be resolved correctly with java6
[ http://jira.codehaus.org/browse/MNG-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86004 ] Matthew Beermann commented on MNG-2793: --- I don't know that this issue affects snapshot _plugins_ only... we've encountered it with snapshot dependencies in general. Snapshot plugins cannot be resolved correctly with java6 Key: MNG-2793 URL: http://jira.codehaus.org/browse/MNG-2793 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Dependencies Affects Versions: 2.0.4 Reporter: Daniel Kulp Attachments: maven-artifact-manager.patch With java 6, builds that use snapshot repositories are consistently failing if the snapshots are not available in the local repository. The error is something like: [INFO] [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::1 for project: null:maven-site-plugin:maven-plugin:2.0-beta-5 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::1 for project: org.apache.maven.plugins:maven-plugins:pom:1 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::1 for project: org.apache.maven:maven-parent:pom:1 from the repository. [DEBUG] maven-install-plugin: using locally installed snapshot [DEBUG] maven-install-plugin: resolved to version 2.2-SNAPSHOT from repository central [DEBUG] Skipping disabled repository central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.plugins:maven-install-plugin Reason: Error getting POM for 'org.apache.maven.plugins:maven-install-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata. org.apache.maven.plugins:maven-install-plugin:pom:2.2-SNAPSHOT from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), central (http://repo1.maven.org/maven2) If the artifacts are first downloaded by building with JDK 1.5, everything works fine. After investigating, the problem is in the transforms that the maven-artifact-manager. With JDK 1.5, the order they run is: org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation org.apache.maven.artifact.transform.SnapshotTransformation but with Java 6, for some reason, the order is: org.apache.maven.artifact.transform.SnapshotTransformation org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation The LatestArtifactTransform is what uses to the metadata to determine the actual version number (for the install plugin, 2.2-SNAPSHOT). The SnapshotTransform then converts that to 2.2-20061118.060401-2 which is what is then downloaded. However, in the java 6 case, the SnapshotTransform is run first and since the version is not a SNAPSHOT version number, it doesn't do any processing so then the downloading ends up looking for 2.2-SNAPSHOT, not the full version, which then fails. I chatted with brett_ on IRC about this: [09:46:35] dkulp OK. I'm trying to track down why my builds are failing with JDK 1.6 [09:46:53] dkulp The issue is the transforms are in a different order with 1.6 than 1.5 [09:47:17] brett_ yikes [09:47:42] dkulp With 1.5, its Latest/Release/Snapshot. [09:47:46] brett_ not sure why that would matter. But I guess sorting the transforms consistently would help. [09:47:50] dkulp With 1.6, it's Snapshot/Latest/Release [09:48:06] brett_ ok, fairly simple to fix in Maven. [09:48:10] dkulp The Latest needs to be before Snapshot. [09:49:08] dkulp I tried changing the order of things in the components.xml. Didn't seem to change anything. But this is plexus stuff which I don't know anything about. [09:49:22] brett_ hmm, it should be populated as a list [09:49:28] brett_ but maybe the list is backed by a map [09:49:35] dkulp Yep. Verified it's and ArrayList [09:49:51] brett_ s/backed/populated by/ [09:50:48] dkulp That would definitely do it. [09:51:21] dkulp Any hints on where to look? [09:51:48] brett_ oh, I would go into plexus [09:51:52] dkulp (or how to debug)? [09:51:58] brett_ sorry, wouldn't [09:52:13] brett_ it's changing too much [09:52:18] brett_ 2.0.5 will be stuck with alpha-10 [09:52:24] brett_ so, need to work around it in Maven [09:53:00] brett_ perhaps just hack the order in the code, and then fix
[jira] Commented: (MRELEASE-122) Versionless Extension causes NullPointerException in release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86005 ] Rene Lenga commented on MRELEASE-122: - I have this one too - without an extension. My workaround.. After providing the tags for connection , tag and url the NPE was gone. before: scm developerConnectionscm:cvs:pserver:192.168.1.20:/usr/cvsarchiv:Test/developerConnection /scm after: scm developerConnectionscm:cvs:pserver:192.168.1.20:/usr/cvsarchiv:Test/developerConnection connection/connection tag/tag url/url /scm . Versionless Extension causes NullPointerException in release:prepare Key: MRELEASE-122 URL: http://jira.codehaus.org/browse/MRELEASE-122 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Stefan Hübner Assigned To: Jason van Zyl Fix For: 2.0-beta-5 Attachments: patch.txt I'm getting a NullPointerException when invoking mvn release:prepare -DdryRun=true (don't know, if the dryRun-parameter makes any difference). See the stack trace below. My POM does make use of the wagon-ssh-extension, but without declaring a certain version of that extension - which is not necessary, as far as I know. A workaround to this is to declare a version to the extension. See this mail thread for a discussion on this issue: http://www.nabble.com/NullPointerException+in+Release+Plugin+2.0-beta-4-t1637385.html#a4434481 Stefan ava.lang.NullPointerException at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-179) Assembled jar includes artifact names in path
[
http://jira.codehaus.org/browse/MASSEMBLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86014
]
Jonathan Komorek commented on MASSEMBLY-179:
Thanks Milos, that workaround works perfectly for me.
Shall I close this issue then, or does anyone believe that this is still an
issue?
Assembled jar includes artifact names in path
-
Key: MASSEMBLY-179
URL: http://jira.codehaus.org/browse/MASSEMBLY-179
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Jonathan Komorek
Priority: Critical
This issue does not occur in 2.1 and began occurring in 2.2-SNAPSHOT
(roughly) a couple months ago.
After assembling a jar, the path for each of the included files begins with
what seems to be ${artifactId}-${version}.${packaging}
This includes files from dependent jars and files from sub-modules - all
files.
The plugin is configured in the POM as follows:
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
executions
execution
id1/id
phasepackage/phase
goals
goalattached/goal
/goals
/execution
/executions
version2.2-SNAPSHOT/version
configuration
descriptorassembly.xml/descriptor
/configuration
/plugin
/plugins
/build
The entire assembly.xml is as follows:
assembly
iddependencies/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
scoperuntime/scope
/dependencySet
/dependencySets
/assembly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-57) Path to application.xml doesn't resolve properly in a multi-module build
[
http://jira.codehaus.org/browse/MEAR-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86015
]
Stephane Nicoll commented on MEAR-57:
-
It's not a bug. You have to specify the ${basedir} in a multi-modules build.
Path to application.xml doesn't resolve properly in a multi-module build
Key: MEAR-57
URL: http://jira.codehaus.org/browse/MEAR-57
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Reporter: Jason Melnick
Priority: Minor
I have three poms - BasePOM - MultiModulePOM - EarPOM. My application.xml
is at the the root of the project in META-INF.
BasePOM declares plugin configuration as such:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
generateApplicationXmlfalse/generateApplicationXml
applicationXmlMETA-INF/application.xml/applicationXml
manifestFileMETA-INF/MANIFEST.MF/manifestFile
archive
manifest
addClasspathfalse/addClasspath
/manifest
manifestFileMETA-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
When EarPOM is run separately the plugin does what it is supposed to do and
finds both the application.xml and MANIFEST.MF.
As soon as I attempt to run a multi-module build using the MultiModulePOM
(which runs the EarPOM as a module) the application.xml can not be found (but
oddly enought the MANIFEST.MF can be found).
If I change the applicationXmlMETA-INF/application.xml/applicationXml to:
applicationXml${basedir}/META-INF/application.xml/applicationXml
it works fine in both solo and multi-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] Closed: (MEAR-57) Path to application.xml doesn't resolve properly in a multi-module build
[
http://jira.codehaus.org/browse/MEAR-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-57.
---
Assignee: Stephane Nicoll
Resolution: Won't Fix
Path to application.xml doesn't resolve properly in a multi-module build
Key: MEAR-57
URL: http://jira.codehaus.org/browse/MEAR-57
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Reporter: Jason Melnick
Assigned To: Stephane Nicoll
Priority: Minor
I have three poms - BasePOM - MultiModulePOM - EarPOM. My application.xml
is at the the root of the project in META-INF.
BasePOM declares plugin configuration as such:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
generateApplicationXmlfalse/generateApplicationXml
applicationXmlMETA-INF/application.xml/applicationXml
manifestFileMETA-INF/MANIFEST.MF/manifestFile
archive
manifest
addClasspathfalse/addClasspath
/manifest
manifestFileMETA-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/plugin
When EarPOM is run separately the plugin does what it is supposed to do and
finds both the application.xml and MANIFEST.MF.
As soon as I attempt to run a multi-module build using the MultiModulePOM
(which runs the EarPOM as a module) the application.xml can not be found (but
oddly enought the MANIFEST.MF can be found).
If I change the applicationXmlMETA-INF/application.xml/applicationXml to:
applicationXml${basedir}/META-INF/application.xml/applicationXml
it works fine in both solo and multi-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] Created: (MAVENUPLOAD-1342) Please sync israfil.net with ibiblio's maven2 repo
Please sync israfil.net with ibiblio's maven2 repo -- Key: MAVENUPLOAD-1342 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1342 Project: maven-upload-requests Issue Type: New Feature Reporter: Christian Gruber Attachments: net.israfil.sh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MEJB-16) clientExcludes generates empty packages i client-jar
[ http://jira.codehaus.org/browse/MEJB-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86019 ] Hans Bausewein commented on MEJB-16: I've noticed something related. Say I have a package structure org/codehaus/*.class org/codehaus/impl/*.class and I want to include only the 'org.codehaus' package without the classes in 'org.codehaus.impl'. I expected I could do: clientIncludes clientIncludeorg/codehaus/*.class/clientInclude /clientIncludes but I still got the 'org.codehaus.impl' package classes included. I had to explicitly exclude the sub package to get rid of them. clientExcludes generates empty packages i client-jar Key: MEJB-16 URL: http://jira.codehaus.org/browse/MEJB-16 Project: Maven 2.x Ejb Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Discovered on MAC OSX, but I dont think it is OS dependent Reporter: Anders Kr. Andersen Assigned To: Stephane Nicoll Priority: Minor Fix For: 2.1 When I use the clientExcludes ... the excluded packages are still package in the jar. But empty. The bigggest problem is probably the visual testing the developer is doing. Seeing that packages remanis in the jar ... and discovering that they are empty simple just takes a little time. I don't think the JVM have any problem with this ? But I don't think it is in the JAR specification either :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-95) Doxia omits /p closing elements
[
http://jira.codehaus.org/browse/DOXIA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86021
]
Dennis Lundberg commented on DOXIA-95:
--
The supplied xdoc example is not valid either.
You should not have a list within a paragraph.
Try this code instead:
{code}
?xml version=1.0 encoding=UTF-8?
document
properties
titletest1/title
/properties
body
section name=section name
ptext
/p
ul
lilist1/li
/ul
p
text2
/p
ul
lilist1/li
/ul
/section
/body
/document
{code}
Doxia omits /p closing elements
-
Key: DOXIA-95
URL: http://jira.codehaus.org/browse/DOXIA-95
Project: doxia
Issue Type: Bug
Reporter: Henning Schmiedehausen
Consider the following xdoc file:
?xml version=1.0 encoding=UTF-8?
document
properties
titletest1/title
/properties
body
section name=section name
ptext
ul
lilist1/li
/ul
text2
ul
lilist1/li
/ul
/p
/section
/body
/document
This renders to the following HTML output:
a name=section name/adiv class=sectionh2section name/h2
ptext
ul
lilist1/li
/ul
text2
ul
lilist1/li
/ul
/div
Please note that there is no closing /p between /ul and /div
This is obviously no valid XHTML.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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-93) xdoc renderer chokes on multiple block elements in a section
[ http://jira.codehaus.org/browse/DOXIA-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86022 ] Dennis Lundberg commented on DOXIA-93: -- There has been an ongoing discussion about this on the Maven users list. See http://mail-archives.apache.org/mod_mbox/maven-users/200701.mbox/[EMAIL PROTECTED] and http://mail-archives.apache.org/mod_mbox/maven-users/200701.mbox/[EMAIL PROTECTED] In short - I have not been able to reproduce this using doxia HEAD, or any other version for that matter. xdoc renderer chokes on multiple block elements in a section Key: DOXIA-93 URL: http://jira.codehaus.org/browse/DOXIA-93 Project: doxia Issue Type: Bug Components: Core Affects Versions: 1.0-alpha-8, 1.0 Reporter: Henning Schmiedehausen Consider the following xdoc file: ?xml version=1.0 encoding=UTF-8? document properties titletest1/title /properties body section name=section name ptext/p ul lilist1/li /ul ptext2/p ul lilist1/li /ul ptext3/p /section /body /document The current doxia HEAD renders this to: a name=section name/adiv class=sectionh2section name/h2 ptext/p ul lilist1/li /ul text2 ul lilist1/li /ul text3 /div Note the missing 'p' tags around text2 and text3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
[ http://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86024 ] Barrett Nuzum commented on MNG-1991: EARs bundling multiple WARs have a need to be able to resolve and bundle transitive dependency to reduce overall WAR size. (skinny WARs) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project -- Key: MNG-1991 URL: http://jira.codehaus.org/browse/MNG-1991 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.2 Reporter: Emmanuel Venisse Fix For: 2.1.x I have a project (continuum-core-it) that need to use all transitive dependencies of a war (continuum-webapp). If i add the war as a dependency of the project with packaging war, war dependencies aren't shown by project, maven doesn't try to resolve them and doesn't add them in classpath. If if replace packaging from war to pom, all dependencies are resolved and added to classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1335) Please upload OpenOffice.org Java/Uno JARs 2.1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86025 ] Mirko Nasato commented on MAVENUPLOAD-1335: --- Alright, please find the new bundles here http://jooreports.sourceforge.net/m2/juh-2.1.0-bundle.jar http://jooreports.sourceforge.net/m2/jurt-2.1.0-bundle.jar http://jooreports.sourceforge.net/m2/ridl-2.1.0-bundle.jar http://jooreports.sourceforge.net/m2/unoil-2.1.0-bundle.jar Please upload OpenOffice.org Java/Uno JARs 2.1.0 Key: MAVENUPLOAD-1335 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1335 Project: maven-upload-requests Issue Type: Task Reporter: Mirko Nasato OpenOffice.org includes some JARs that can be used in a standalone Java app to connect to a running OpenOffice.org instance. The OpenOffice.org team agreed to distributing those JARs through Maven 2 and assigned the task to myself http://www.openoffice.org/issues/show_bug.cgi?id=71358 Please find the bundles here http://jooreports.sourceforge.net/m2/openoffice.org-juh-2.1.0-bundle.jar http://jooreports.sourceforge.net/m2/openoffice.org-jurt-2.1.0-bundle.jar http://jooreports.sourceforge.net/m2/openoffice.org-ridl-2.1.0-bundle.jar http://jooreports.sourceforge.net/m2/openoffice.org-unoil-2.1.0-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-976) Refactor Notifiers: Seprate hierarchy for Project and Project Group
[ http://jira.codehaus.org/browse/CONTINUUM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-976. -- Assignee: Emmanuel Venisse (was: Rahul Thakur) Resolution: Fixed Fix Version/s: 1.1 Already done Refactor Notifiers: Seprate hierarchy for Project and Project Group --- Key: CONTINUUM-976 URL: http://jira.codehaus.org/browse/CONTINUUM-976 Project: Continuum Issue Type: Task Components: Notifier - IRC, Notifier - Jabber, Notifier - Mail, Notifier - MSN, Web interface Affects Versions: 1.1 Reporter: Rahul Thakur Assigned To: Emmanuel Venisse Fix For: 1.1 Attachments: CONTINUUM-967b.patch, CONTINUUM-976.patch, CONTINUUM-976a.patch Refactor Notifiers hierarchy to be separate for Project and Project Group. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1343) Falcon upload please
Falcon upload please Key: MAVENUPLOAD-1343 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1343 Project: maven-upload-requests Issue Type: Task Reporter: Charles Lee http://downloads.sourceforge.net/falcon/falconcore-0.0.6-bundle.jar?use_mirror=heanet http://downloads.sourceforge.net/falcon/falconcore-0.0.6.jar?use_mirror=heanet This is a flexible binding framework. I will be great of ppl can download it from maven :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1339) WebworkWebflow version 1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schneider closed MAVENUPLOAD-1339. -- Resolution: Incomplete Thanks for looking at this. I will post a new version with these problems resolved. WebworkWebflow version 1.0.1 Key: MAVENUPLOAD-1339 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1339 Project: maven-upload-requests Issue Type: Task Reporter: Tom Schneider Attachments: webworkwebflow-plugin-1.0.1-bundle.jar http://webworkwebflow.googlecode.com/files/webworkwebflow-plugin-1.0.1-bundle.jar http://code.google.com/p/webworkwebflow/ http://wiki.opensymphony.com/display/WW/Spring+Webflow WebworkWebflow provides integration between Spring Webflow and Webwork. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
