[jira] Commented: (MSITE-441) head generated at bad place in html (xdoc format)
[ http://jira.codehaus.org/browse/MSITE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203922#action_203922 ] Michenaud Laurent commented on MSITE-441: - Thanks a lot. My problem was that I declared the site plugin with it version in the reporting part instead of the build part in pom.xml. I have another problem. Respecting the xsd, i have to declare twice the title (in properties and in head) and it generates a warning. properties titleMy title/title author email=*Michel/author /properties head titleMy title/title link href=css/mycss.css type=text/css media=screen/ /head head generated at bad place in html (xdoc format) --- Key: MSITE-441 URL: http://jira.codehaus.org/browse/MSITE-441 Project: Maven 2.x Site Plugin Issue Type: Bug Components: doxia integration Affects Versions: 2.1 Environment: Ubuntu, maven 2.2.1, Java 6 Reporter: Michenaud Laurent Assignee: Lukas Theussl Attachments: msite-441.zip Here is a simple test.xml with a head tag. ?xml version=1.0 encoding=ISO-8859-1? document xmlns=http://maven.apache.org/XDOC/2.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd; head link href=css/mysite.css type=text/css media=print / /head body section name=Test Hello /section /body /document In the generated html : div id=bodyColumn div id=contentBox headlink href=css/mysite.css type=text/css media=print/head = bad position div class=sectionh2a name=Test/aTest/h2 -- 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-440) Site document validation fails if unable to retrieve schema (in offline mode)
[
http://jira.codehaus.org/browse/MSITE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203925#action_203925
]
Marcel May commented on MSITE-440:
--
Here's a thread stack for the hanging connection confirming Dave.
Anyone using schemas - eg for xdoc - should skip version 2.1 of the plugin -
wish I'd tested when the voting was going on :-(
{code}
main prio=10 tid=0x4129a000 nid=0x71a3 runnable [0x7f65375a5000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
- locked 0x7f6525eba068 (a java.net.SocksSocketImpl)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:525)
at java.net.Socket.connect(Socket.java:475)
at java.net.Socket.init(Socket.java:372)
at java.net.Socket.init(Socket.java:246)
at
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:80)
at
org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:122)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.toByteArray(AbstractXmlParser.java:1024)
at
org.apache.maven.doxia.parser.AbstractXmlParser$CachedFileEntityResolver.resolveEntity(AbstractXmlParser.java:958)
at org.apache.xerces.util.EntityResolverWrapper.resolveEntity(Unknown
Source)
at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.maven.doxia.parser.AbstractXmlParser.validate(AbstractXmlParser.java:635)
at
org.apache.maven.doxia.parser.AbstractXmlParser.parse(AbstractXmlParser.java:142)
at
org.apache.maven.doxia.parser.XhtmlBaseParser.parse(XhtmlBaseParser.java:90)
at
org.apache.maven.doxia.module.xdoc.XdocParser.parse(XdocParser.java:104)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:63)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:404)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:328)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:132)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:142)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:109)
{code}
The build finally fails with:
{code}
Dec 23, 2009 11:06:15 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: I/O exception (java.net.ConnectException) caught when processing request:
Connection timed out
Dec 23, 2009 11:06:15 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: Retrying request
Dec 23, 2009 11:09:24 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: I/O exception (java.net.ConnectException) caught when processing request:
Connection
[jira] Created: (MDEPLOY-115) Deploy should not fail if distributionManagement and repository does not exist when used with -DaltDeploymentRepository
Deploy should not fail if distributionManagement and repository does not
exist when used with -DaltDeploymentRepository
---
Key: MDEPLOY-115
URL: http://jira.codehaus.org/browse/MDEPLOY-115
Project: Maven 2.x Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.4
Reporter: Geoffrey De Smet
I have a pom with no distributionManagement section.
When I do:
{code}
mvn -DskipTests -DupdateReleaseInfo=true
-DaltDeploymentRepository=ggg-deploy::default::scp://ggg/maven/maven2/deploy
clean deploy
{code}
I get this error:
{code}
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-deploy-plugin:2.4
check that the following section of the pom.xml is present and correct:
distributionManagement
!-- use the following if you're not using a snapshot version. --
repository
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/repository
!-- use the following if you ARE using a snapshot version. --
snapshotRepository
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/snapshotRepository
/distributionManagement
Cause: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot
be instantiated
{code}
However, since I supply the altDeploymentRepository parameter, it shouldn't
require that section in the 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: (MDEPLOY-115) Deploy should not fail if distributionManagement and repository does not exist when used with -DaltDeploymentRepository
[
http://jira.codehaus.org/browse/MDEPLOY-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MDEPLOY-115.
-
Resolution: Duplicate
Assignee: Benjamin Bentmann
Deploy should not fail if distributionManagement and repository does not
exist when used with -DaltDeploymentRepository
---
Key: MDEPLOY-115
URL: http://jira.codehaus.org/browse/MDEPLOY-115
Project: Maven 2.x Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 2.4
Reporter: Geoffrey De Smet
Assignee: Benjamin Bentmann
I have a pom with no distributionManagement section.
When I do:
{code}
mvn -DskipTests -DupdateReleaseInfo=true
-DaltDeploymentRepository=ggg-deploy::default::scp://ggg/maven/maven2/deploy
clean deploy
{code}
I get this error:
{code}
[INFO] Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-deploy-plugin:2.4
check that the following section of the pom.xml is present and correct:
distributionManagement
!-- use the following if you're not using a snapshot version. --
repository
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/repository
!-- use the following if you ARE using a snapshot version. --
snapshotRepository
idrepo/id
nameRepository Name/name
urlscp://host/path/to/repo/url
/snapshotRepository
/distributionManagement
Cause: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot
be instantiated
{code}
However, since I supply the altDeploymentRepository parameter, it shouldn't
require that section in the 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] Updated: (MECLIPSE-629) Eclipse doesn't accept absolute path in output property of the .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent ASTRUC updated MECLIPSE-629: Attachment: patch.txt A proposal of patch Eclipse doesn't accept absolute path in output property of the .classpath - Key: MECLIPSE-629 URL: http://jira.codehaus.org/browse/MECLIPSE-629 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: Vincent ASTRUC Attachments: patch.txt When the outputDirectory of the pom.xml is an absolute path, meclispe would have generate linked resource in .projet and use this link in .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: (MWAR-211) Ability to rename a dependency's jar when putting it on the lib folder
[
http://jira.codehaus.org/browse/MWAR-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203933#action_203933
]
Johan Sjöberg commented on MWAR-211:
Using outputFileNameMapping to control the name of the jar-file produced by
the archiveClasses tag has _SERIOUS_ side effects. Sure, the jar-file
produced from our sources are given the name, but so are also every other
external dependency (declared by maven dependency.../dependency tags).
So again, I really propose a tag similar to
archiveNamemyname.jar/archiveName, to be able to control the name of the
jar produced from the project sources.
pom.xml excerpt using outputFileNameMapping:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1-beta-1/version
configuration
archiveClassestrue/archiveClasses
outputFileNameMappingprefix-${project.artifactId}-${project.version}.jar/outputFileNameMapping
/configuration
/plugin
Ability to rename a dependency's jar when putting it on the lib folder
--
Key: MWAR-211
URL: http://jira.codehaus.org/browse/MWAR-211
Project: Maven 2.x WAR Plugin
Issue Type: New Feature
Reporter: Magno Machado Paulo
Attachments: TestMaven.rar
Maven put on my 'lib' folder the jars of my project's dependencies named like
artefactId-version.jar
This is a problem when we need to reference the jar filename from sourcecode,
because if we change the dependency version, we have to track all source code
references to it and correct them. This is the case when importing a taglib
into a jsp page
It would be better if Maven put only artefactId.jar on the lib folder. And
even better if it let us use any custom name we want for the dependencies. If
no name is specified, then it could use the current pattern.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-269) Perforce support doesn't work when there's a space in the local path
[
http://jira.codehaus.org/browse/SCM-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203948#action_203948
]
Cliff Evans commented on SCM-269:
-
To make this work the Repo path in the Clientspec needs to be quoted. Changing
the createClientspec method in the
org/apache/maven/scm/provider/perforce/PerforceScmProvider.java file to that
shown below fixes the issue. (I've changed the style of the section I changed
to make it standout more.)
{noformat}
/*
* Clientspec name can be overridden with the system property below. I
don't
* know of any way for this code to get access to maven's settings.xml so
this
* is the best I can do.
*
* Sample clientspec:
Client: mperham-mikeperham-dt-maven
Root: d:\temp\target
Owner: mperham
View:
//depot/sandbox/mperham/tsa/tsa-domain/...
//mperham-mikeperham-dt-maven/...
Description:
Created by maven-scm-provider-perforce
*/
public static String createClientspec( ScmLogger logger,
PerforceScmProviderRepository repo, File workDir,
String repoPath )
{
String clientspecName = getClientspecName( logger, repo, workDir );
String userName = getUsername( logger, repo );
String rootDir;
try
{
// SCM-184
rootDir = workDir.getCanonicalPath();
}
catch ( IOException ex )
{
//getLogger().error(Error getting canonical path for working
directory: + workDir, ex);
rootDir = workDir.getAbsolutePath();
}
StringBuffer buf = new StringBuffer();
buf.append( Client: ).append( clientspecName ).append( NEWLINE );
buf.append( Root: ).append( rootDir ).append( NEWLINE );
buf.append( Owner: ).append( userName ).append( NEWLINE );
// SCM-269
buf.append( View: ).append( NEWLINE )
.append( \t\ ).append( PerforceScmProvider.getCanonicalRepoPath(
repoPath ) )
.append( \ // ).append( clientspecName ).append( /... ).append(
NEWLINE );
buf.append( Description: ).append( NEWLINE );
buf.append( \t ).append( Created by maven-scm-provider-perforce
).append( NEWLINE );
return buf.toString();
}
{noformat}
A unit test for it might look something like:
{noformat}
public void testCreateClientSpec ()
throws
Exception
{
File workDir = new File ( /work/directory );
ScmRepository repo = makeScmRepository(
scm:perforce:host://depot/projects/path name );
PerforceScmProviderRepository p4Repo = (PerforceScmProviderRepository)
repo.getProviderRepository();
String cs = createClientspec ( null, p4Repo, workDir,
//depot/projects/path name );
assertTrue( cs.contains ( \//depot/projects/path name/...\ );
}
{noformat}
but I haven't tested this since I don't have access to the SVN repo other than
through a browser. Paranoid SAs.
Regards,
Cliff
Perforce support doesn't work when there's a space in the local path
Key: SCM-269
URL: http://jira.codehaus.org/browse/SCM-269
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-perforce
Affects Versions: 1.0-beta-4
Reporter: David Jackman
Assignee: Mike Perham
Fix For: future
Create a view of a Maven project in Perforce in a local directory whose path
contains a space. Perform some SCM goal (I was trying to scm:update). It
won't work. The error message is very cryptic (Unable to sync. Are you
logged in?). From the looks of it, the client command (which is run just
before the sync command) has problems, but these problems aren't reported. I
think the main problem is the fact that the local path is used in the client
name, and client names can't contain spaces. Other elements of the client
(root and view) also will contain spaces, but I don't know if Perforce has a
problem with these.
--
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-2700) Syncing OpenFaces repository with the central repository
Syncing OpenFaces repository with the central repository Key: MAVENUPLOAD-2700 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2700 Project: Maven Upload Requests Issue Type: Wish Reporter: Andrew Shapovalov Hi! Please add this sync string to your scheduler: org.openfaces,ma...@sshrepo.openfaces.org:/home/maven/repository,rsync_ssh,Andrew Shapovalov,andrew.shapova...@teamdev.com Sincerely, Andrew -- 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-441) head generated at bad place in html (xdoc format)
[ http://jira.codehaus.org/browse/MSITE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203999#action_203999 ] Lukas Theussl commented on MSITE-441: - True it's confusing, but the warning is harmless, it only tells you which title is being used actually. I'd recommend to not use both properties and head, just put the author information into a meta tag and remove the properties. head generated at bad place in html (xdoc format) --- Key: MSITE-441 URL: http://jira.codehaus.org/browse/MSITE-441 Project: Maven 2.x Site Plugin Issue Type: Bug Components: doxia integration Affects Versions: 2.1 Environment: Ubuntu, maven 2.2.1, Java 6 Reporter: Michenaud Laurent Assignee: Lukas Theussl Attachments: msite-441.zip Here is a simple test.xml with a head tag. ?xml version=1.0 encoding=ISO-8859-1? document xmlns=http://maven.apache.org/XDOC/2.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd; head link href=css/mysite.css type=text/css media=print / /head body section name=Test Hello /section /body /document In the generated html : div id=bodyColumn div id=contentBox headlink href=css/mysite.css type=text/css media=print/head = bad position div class=sectionh2a name=Test/aTest/h2 -- 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: (MPDF-36) Cannot include extra images
Cannot include extra images --- Key: MPDF-36 URL: http://jira.codehaus.org/browse/MPDF-36 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Lukas Theussl I have a use case where I want to include images in the pdf that are not part of the main site. I use the maven-resources-plugin to copy those images (from src/main/resources/) to target/pdf/images/ in the pre-site phase. However, those images are gone again when I run site (which triggers the pdf), because the pdf:pdf goal deletes the whole working directory before starting to work. I don't know if my problem can be solved differently but I also don't see why we delete the workingDirectory at every run, is there a special reason for 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] Closed: (MPDF-36) Cannot include extra images
[ http://jira.codehaus.org/browse/MPDF-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-36. - Resolution: Fixed Fix Version/s: 1.2 Assignee: Lukas Theussl Fixed in [r893623|http://svn.apache.org/viewvc?view=revisionrevision=893623] Cannot include extra images --- Key: MPDF-36 URL: http://jira.codehaus.org/browse/MPDF-36 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Lukas Theussl Assignee: Lukas Theussl Fix For: 1.2 I have a use case where I want to include images in the pdf that are not part of the main site. I use the maven-resources-plugin to copy those images (from src/main/resources/) to target/pdf/images/ in the pre-site phase. However, those images are gone again when I run site (which triggers the pdf), because the pdf:pdf goal deletes the whole working directory before starting to work. I don't know if my problem can be solved differently but I also don't see why we delete the workingDirectory at every run, is there a special reason for 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
