[jira] [Commented] (MPLUGIN-296) java.lang.ClassNotFoundException: org.apache.maven.plugins.annotations.Execute
[
https://issues.apache.org/jira/browse/MPLUGIN-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135718#comment-15135718
]
Hervé Boutemy commented on MPLUGIN-296:
---
can we have an IT in the plugin to show the issue, please?
when does this failure happen, that was not detected until now?
> java.lang.ClassNotFoundException: org.apache.maven.plugins.annotations.Execute
> --
>
> Key: MPLUGIN-296
> URL: https://issues.apache.org/jira/browse/MPLUGIN-296
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
> Environment: Apache Maven 3.4.0-SNAPSHOT
> (7a009b7caf970730ea37641be7a315a71bb68f09; 2016-02-05T19:32:21+01:00)
> Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: /usr/local/jdk-1.8.0/jre
> Default locale: en_DE, platform encoding: UTF-8
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Blocker
> Fix For: 3.5
>
>
> The plugin dependency on 'maven-plugin-annotations' must not use scope
> 'provided'. The scope of the annotations for the project using them can use
> 'provided'. The plugin classpath is different.
> {code}
> [INFO] --- maven-plugin-plugin:3.4:descriptor (default-descriptor) @
> mng-5783-plugin-dependency-filtering-plugin ---
> [WARNING] Using platform encoding (UTF-8 actually) to read mojo metadata,
> i.e. build is platform dependent!
> [INFO] Mojo extractor with id: java-javadoc found 1 mojo descriptors.
> [WARNING] Error injecting:
> org.apache.maven.tools.plugin.extractor.annotations.JavaAnnotationsMojoDescriptorExtractor
> java.lang.NoClassDefFoundError: org/apache/maven/plugins/annotations/Execute
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at
> com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:688)
> at
> com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:380)
> at
> com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:164)
> at
> com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:613)
> at
> com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:569)
> at
> com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:555)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:884)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:805)
> at
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:282)
> at
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:214)
> at
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:1006)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
> at
> com.google.inject.internal
[jira] [Commented] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push
[
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135814#comment-15135814
]
ASF GitHub Bot commented on SCM-811:
GitHub user eddiewebb opened a pull request:
https://github.com/apache/maven-scm/pull/45
Resolves critical security bug SCM-811
This PR addresses https://issues.apache.org/jira/browse/SCM-811 by allowing
the shared ScmResult in the api module to mask known patterns. Covers SVN and
git patterns (which are the ones impacting us and likely most popular).
Includes simple unit test to validate passwords aren't leaked.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Libertymutual/maven-scm SCM-811
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven-scm/pull/45.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #45
commit 8785b85e0d6273f88e7bd173c5d59d0e2c1148c2
Author: EDWARD WEBB
Date: 2016-02-06T14:58:36Z
#resolves SCM-811 by masking command output in ScmResult class used by all
SCM operations
commit 9d009e8f14c0dff99c377b8991bdd59b519f0d33
Author: EDWARD WEBB
Date: 2016-02-06T15:15:41Z
Simple test for SCM-811 ensures ouptut is masked
> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-git
>Affects Versions: 1.9.4
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push
> https://myuser:@myserver.com:8081/scm/project/project.git
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password)
> then I see in log
> {quote}
> [ERROR] fatal: unable to access
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes
> security problems when someone else can see my password if build failed. I
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-146) don't translate APT source comments into output comments
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-146. Resolution: Fixed ssi macro added for DOXIA-532 > don't translate APT source comments into output comments > > > Key: DOXIASITETOOLS-146 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-146 > Project: Maven Doxia Sitetools > Issue Type: Wish > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > see DOXIA-482: when Doxia is used in a site, parsing markup and translating > it to HTML, comments in source markup are not really meant for output site -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DOXIASITETOOLS-93) request-scoped default Velocity Tools are not accessible
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned DOXIASITETOOLS-93: Assignee: Michael Osipov > request-scoped default Velocity Tools are not accessible > > > Key: DOXIASITETOOLS-93 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Michael Osipov > Fix For: 1.7 > > > only application scoped are available: $esc, ... > nut not $context, for example > see > http://svn.apache.org/viewvc/velocity/tools/tags/2.0/src/main/java/org/apache/velocity/tools/generic/tools.xml?view=markup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MPLUGIN-296) java.lang.ClassNotFoundException: org.apache.maven.plugins.annotations.Execute
[
https://issues.apache.org/jira/browse/MPLUGIN-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135893#comment-15135893
]
Christian Schulte commented on MPLUGIN-296:
---
Will do. Depends on the Aether version used by Maven. With [Pull Request
1|https://github.com/jvanzyl/aether-core/pull/1] applied, direct dependencies
will no longer be filtered out unintended. Currently the direct dependency on
the annotations (provided) will be filtered out by the
'ScopeDependencySelector' so that the transitive dependency will be used. With
the patch applied the direct dependency will no longer be filtered out (nearer)
and will then not get resolved due to the provided scope.
> java.lang.ClassNotFoundException: org.apache.maven.plugins.annotations.Execute
> --
>
> Key: MPLUGIN-296
> URL: https://issues.apache.org/jira/browse/MPLUGIN-296
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
> Environment: Apache Maven 3.4.0-SNAPSHOT
> (7a009b7caf970730ea37641be7a315a71bb68f09; 2016-02-05T19:32:21+01:00)
> Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: /usr/local/jdk-1.8.0/jre
> Default locale: en_DE, platform encoding: UTF-8
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Blocker
> Fix For: 3.5
>
>
> The plugin dependency on 'maven-plugin-annotations' must not use scope
> 'provided'. The scope of the annotations for the project using them can use
> 'provided'. The plugin classpath is different.
> {code}
> [INFO] --- maven-plugin-plugin:3.4:descriptor (default-descriptor) @
> mng-5783-plugin-dependency-filtering-plugin ---
> [WARNING] Using platform encoding (UTF-8 actually) to read mojo metadata,
> i.e. build is platform dependent!
> [INFO] Mojo extractor with id: java-javadoc found 1 mojo descriptors.
> [WARNING] Error injecting:
> org.apache.maven.tools.plugin.extractor.annotations.JavaAnnotationsMojoDescriptorExtractor
> java.lang.NoClassDefFoundError: org/apache/maven/plugins/annotations/Execute
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at
> com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:688)
> at
> com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:380)
> at
> com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:164)
> at
> com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:613)
> at
> com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:569)
> at
> com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:555)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:884)
> at
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:805)
> at
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:282)
> at
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:214)
> at
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:1006)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
> at
> com.google.inject.internal.InjectorImpl.getInstance(InjectorI
[jira] [Commented] (DOXIASITETOOLS-94) add plexus container to Velocity context
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135924#comment-15135924 ] Hudson commented on DOXIASITETOOLS-94: -- FAILURE: Integrated in maven-plugins #5052 (See [https://builds.apache.org/job/maven-plugins/5052/]) [DOXIASITETOOLS-94] add plexus container to Velocity context (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1728865]) * maven-site-plugin/src/it/doxia-formats/src/site/apt/velocity-context.apt.vm > add plexus container to Velocity context > > > Key: DOXIASITETOOLS-94 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-94 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy > Fix For: 1.7 > > > this will permit plexus components retrieving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-94) add plexus container to Velocity context
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-94. --- Resolution: Fixed Assignee: Hervé Boutemy > add plexus container to Velocity context > > > Key: DOXIASITETOOLS-94 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-94 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > this will permit plexus components retrieving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5972) error: unmappable character for encoding UTF-8
[
https://issues.apache.org/jira/browse/MNG-5972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5972:
---
Description:
I have stated encoding as UTF-8 in my pom. still i m getting this error
[error]: unmappable character for encoding UTF-8
on both windows n linux.
{code:xml}${java-version}
${java-version}
UTF-8{code}
was:
I have stated encoding as UTF-8 in my pom. still i m getting this error
[error]: unmappable character for encoding UTF-8
on both windows n linux.
${java-version}
${java-version}
UTF-8
> error: unmappable character for encoding UTF-8
> --
>
> Key: MNG-5972
> URL: https://issues.apache.org/jira/browse/MNG-5972
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.1.0
> Environment: windows,linux
>Reporter: Nitin Modi
> Labels: encoding
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I have stated encoding as UTF-8 in my pom. still i m getting this error
> [error]: unmappable character for encoding UTF-8
> on both windows n linux.
> {code:xml}${java-version}
> ${java-version}
> UTF-8{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-94) add plexus container to Velocity context
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15135980#comment-15135980 ] Hudson commented on DOXIASITETOOLS-94: -- SUCCESS: Integrated in doxia-all #236 (See [https://builds.apache.org/job/doxia-all/236/]) [DOXIASITETOOLS-94] added plexus container to Velocity context (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1728864]) * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java * ./doxia-sitetools/doxia-site-renderer/src/site/apt/index.apt.vm > add plexus container to Velocity context > > > Key: DOXIASITETOOLS-94 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-94 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > this will permit plexus components retrieving -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-723) "About" report generated even though index.apt is available in "generated-site"
[ https://issues.apache.org/jira/browse/MSITE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136009#comment-15136009 ] Hudson commented on MSITE-723: -- FAILURE: Integrated in maven-plugins #5055 (See [https://builds.apache.org/job/maven-plugins/5055/]) [MSITE-723] render generated-site before reports, in case content was generated in pre-site phase (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1728881]) * maven-site-plugin/src/it/MSITE-723 * maven-site-plugin/src/it/MSITE-723/index.apt * maven-site-plugin/src/it/MSITE-723/invoker.properties * maven-site-plugin/src/it/MSITE-723/pom.xml * maven-site-plugin/src/it/MSITE-723/verify.groovy * maven-site-plugin/src/main/java/org/apache/maven/plugins/site/render/SiteMojo.java > "About" report generated even though index.apt is available in > "generated-site" > --- > > Key: MSITE-723 > URL: https://issues.apache.org/jira/browse/MSITE-723 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 2.0, 3.0, 3.4 >Reporter: Andrius Velykis > Fix For: 3.5 > > Attachments: mvn-site-index.zip > > > Normally, if there is an apt/index.apt file in the /src/site directory, About > report is not generated, and the following message is displayed: Skipped > "About" report, file "index.html" already exists for the English version. > Expecting the same behaviour, I have a situation, where the index.apt file is > generated automatically (e.g. copied from somewhere) during `pre-site` phase. > maven-site-plugin allows specifying an additional `generatedSiteDirectory` > parameter for these files (see > http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html). > However, in this case, the "About" report is generated and overrides the > copied file from `generatedSiteDirectory` parameter. > I would expect the "About" report to be not generated, if index.apt is > available in the `generatedSiteDirectory`. > I have attached a sample project, which uses `antrun` to copy a file to > /target/generated-site/apt/index.apt. When you run `mvn site`, it will still > display the default "About" page. As an example that `generatedSiteDirectory` > works, I also copy the same file to index-copy.apt and an index-copy.html is > generated correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-723) "About" report generated even though index.apt is available in "generated-site"
[ https://issues.apache.org/jira/browse/MSITE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSITE-723. --- Resolution: Fixed Assignee: Hervé Boutemy > "About" report generated even though index.apt is available in > "generated-site" > --- > > Key: MSITE-723 > URL: https://issues.apache.org/jira/browse/MSITE-723 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 2.0, 3.0, 3.4 >Reporter: Andrius Velykis >Assignee: Hervé Boutemy > Fix For: 3.5 > > Attachments: mvn-site-index.zip > > > Normally, if there is an apt/index.apt file in the /src/site directory, About > report is not generated, and the following message is displayed: Skipped > "About" report, file "index.html" already exists for the English version. > Expecting the same behaviour, I have a situation, where the index.apt file is > generated automatically (e.g. copied from somewhere) during `pre-site` phase. > maven-site-plugin allows specifying an additional `generatedSiteDirectory` > parameter for these files (see > http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html). > However, in this case, the "About" report is generated and overrides the > copied file from `generatedSiteDirectory` parameter. > I would expect the "About" report to be not generated, if index.apt is > available in the `generatedSiteDirectory`. > I have attached a sample project, which uses `antrun` to copy a file to > /target/generated-site/apt/index.apt. When you run `mvn site`, it will still > display the default "About" page. As an example that `generatedSiteDirectory` > works, I also copy the same file to index-copy.apt and an index-copy.html is > generated correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-147) link breadcrumbs to index.html instead of directory (like menus)
Hervé Boutemy created DOXIASITETOOLS-147: Summary: link breadcrumbs to index.html instead of directory (like menus) Key: DOXIASITETOOLS-147 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-147 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Decoration model Affects Versions: 1.6 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.7 see MSITE-743 menus contain links to index.html but breacrumbs to directory: should be consistent with menus -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSITE-743) Automatic breadcrumbs generates URLs inconsistent with menus: should point to index.html
[ https://issues.apache.org/jira/browse/MSITE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-743: Summary: Automatic breadcrumbs generates URLs inconsistent with menus: should point to index.html (was: Automatic breadcrumbs generates incorrect URL) > Automatic breadcrumbs generates URLs inconsistent with menus: should point to > index.html > > > Key: MSITE-743 > URL: https://issues.apache.org/jira/browse/MSITE-743 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.4 >Reporter: Peter Bäckman >Priority: Minor > Fix For: 3.5 > > Attachments: BreadcrumbBug.zip > > > With a maven structure like: > -TOP (with site.xml defining breadcrumb for TOP) > --CONTAINER (no site.xml) > ---LEAF (with site.xml) > > For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF. > CONTAINER with link is automatically generated. > I also have defined to get a link to the LEAFs parent > (=CONTAINER). > In the breadcrumb the CONTAINER URL is ...site/ContainerModule and in the > left menu the CONTAINER URL is ...site/ContainerModule/index.html. The menu > is correct and the breadcrumb wrong since it lacks the index.html part. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSITE-743) Automatic breadcrumbs generates URLs inconsistent with menus: should point to index.html
[
https://issues.apache.org/jira/browse/MSITE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MSITE-743:
Description:
With a maven structure like:
-TOP (with site.xml defining breadcrumb for TOP)
--CONTAINER (no site.xml)
---LEAF (with site.xml)
For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
CONTAINER with link is automatically generated.
I also have defined to get a link to the LEAFs parent
(=CONTAINER).
In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
left menu the CONTAINER URL is ...site/ContainerModule/index.html. The menu is
correct and the breadcrumb wrong since it lacks the index.html part.
was:
With a maven structure like:
-TOP (with site.xml defining breadcrumb for TOP)
--CONTAINER (no site.xml)
---LEAF (with site.xml)
For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
CONTAINER with link is automatically generated.
I also have defined to get a link to the LEAFs parent
(=CONTAINER).
In the breadcrumb the CONTAINER URL is ...site/ContainerModule and in the left
menu the CONTAINER URL is ...site/ContainerModule/index.html. The menu is
correct and the breadcrumb wrong since it lacks the index.html part.
> Automatic breadcrumbs generates URLs inconsistent with menus: should point to
> index.html
>
>
> Key: MSITE-743
> URL: https://issues.apache.org/jira/browse/MSITE-743
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.4
>Reporter: Peter Bäckman
>Priority: Minor
> Fix For: 3.5
>
> Attachments: BreadcrumbBug.zip
>
>
> With a maven structure like:
> -TOP (with site.xml defining breadcrumb for TOP)
> --CONTAINER (no site.xml)
> ---LEAF (with site.xml)
>
> For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
> CONTAINER with link is automatically generated.
> I also have defined to get a link to the LEAFs parent
> (=CONTAINER).
> In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
> left menu the CONTAINER URL is ...site/ContainerModule/index.html. The menu
> is correct and the breadcrumb wrong since it lacks the index.html part.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MSITE-743) Automatic breadcrumbs generates URLs inconsistent with menus: should point to index.html
[
https://issues.apache.org/jira/browse/MSITE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MSITE-743:
Description:
With a maven structure like:
-TOP (with site.xml defining breadcrumb for TOP)
--CONTAINER (no site.xml)
---LEAF (with site.xml)
For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
CONTAINER with link is automatically generated.
I also have defined to get a link to the LEAFs parent
(=CONTAINER).
In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
left menu the CONTAINER URL is {{...site/ContainerModule/index.html}}. The menu
is correct and the breadcrumb wrong since it lacks the {{index.html}} part.
was:
With a maven structure like:
-TOP (with site.xml defining breadcrumb for TOP)
--CONTAINER (no site.xml)
---LEAF (with site.xml)
For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
CONTAINER with link is automatically generated.
I also have defined to get a link to the LEAFs parent
(=CONTAINER).
In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
left menu the CONTAINER URL is ...site/ContainerModule/index.html. The menu is
correct and the breadcrumb wrong since it lacks the index.html part.
> Automatic breadcrumbs generates URLs inconsistent with menus: should point to
> index.html
>
>
> Key: MSITE-743
> URL: https://issues.apache.org/jira/browse/MSITE-743
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.4
>Reporter: Peter Bäckman
>Priority: Minor
> Fix For: 3.5
>
> Attachments: BreadcrumbBug.zip
>
>
> With a maven structure like:
> -TOP (with site.xml defining breadcrumb for TOP)
> --CONTAINER (no site.xml)
> ---LEAF (with site.xml)
>
> For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
> CONTAINER with link is automatically generated.
> I also have defined to get a link to the LEAFs parent
> (=CONTAINER).
> In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
> left menu the CONTAINER URL is {{...site/ContainerModule/index.html}}. The
> menu is correct and the breadcrumb wrong since it lacks the {{index.html}}
> part.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-93) request-scoped default Velocity Tools are not accessible
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-93. Resolution: Fixed Fixed with [r1728892|http://svn.apache.org/r1728892]. > request-scoped default Velocity Tools are not accessible > > > Key: DOXIASITETOOLS-93 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Michael Osipov > Fix For: 1.7 > > > only application scoped are available: $esc, ... > nut not $context, for example > see > http://svn.apache.org/viewvc/velocity/tools/tags/2.0/src/main/java/org/apache/velocity/tools/generic/tools.xml?view=markup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-147) link breadcrumbs to index.html instead of directory (like menus)
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136036#comment-15136036 ] Hudson commented on DOXIASITETOOLS-147: --- SUCCESS: Integrated in doxia-all #237 (See [https://builds.apache.org/job/doxia-all/237/]) [DOXIASITETOOLS-147] link breadcrumbs to index.html instead of directory (like menus) (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1728890]) * ./doxia-sitetools/doxia-decoration-model/src/main/java/org/apache/maven/doxia/site/decoration/inheritance/DefaultDecorationModelInheritanceAssembler.java * ./doxia-sitetools/doxia-decoration-model/src/test/java/org/apache/maven/doxia/site/decoration/inheritance/DecorationModelInheritenceAssemblerTest.java * ./doxia-sitetools/doxia-decoration-model/src/test/resources/merged.xml > link breadcrumbs to index.html instead of directory (like menus) > > > Key: DOXIASITETOOLS-147 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-147 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Decoration model >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > see MSITE-743 > menus contain links to index.html > but breacrumbs to directory: should be consistent with menus -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOXIASITETOOLS-148) Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
Michael Osipov created DOXIASITETOOLS-148:
-
Summary: Remove SiteRenderingContext#publishDate (undo
DOXIASITETOOLS-63)
Key: DOXIASITETOOLS-148
URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-148
Project: Maven Doxia Sitetools
Issue Type: Task
Components: Site renderer
Affects Versions: 1.6
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 1.7
The field {{publishDate}} has been introduced DOXIATESITETOOLS-63 but cannot be
set anywhere. Either provide a sane setting option including proper
documentation or drop it completely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-743) Automatic breadcrumbs generates URLs inconsistent with menus: should point to index.html
[
https://issues.apache.org/jira/browse/MSITE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136040#comment-15136040
]
Hudson commented on MSITE-743:
--
FAILURE: Integrated in maven-plugins #5056 (See
[https://builds.apache.org/job/maven-plugins/5056/])
[MSITE-743] updated breadcrumbs URLs to be consistent with menus: point to
index.html thanks to DOXIASITETOOLS-147 (hboutemy:
[http://svn.apache.org/viewvc/?view=rev&rev=1728891])
* maven-site-plugin/src/it/inheritance-interpolation/verify.groovy
> Automatic breadcrumbs generates URLs inconsistent with menus: should point to
> index.html
>
>
> Key: MSITE-743
> URL: https://issues.apache.org/jira/browse/MSITE-743
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.4
>Reporter: Peter Bäckman
>Priority: Minor
> Fix For: 3.5
>
> Attachments: BreadcrumbBug.zip
>
>
> With a maven structure like:
> -TOP (with site.xml defining breadcrumb for TOP)
> --CONTAINER (no site.xml)
> ---LEAF (with site.xml)
>
> For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
> CONTAINER with link is automatically generated.
> I also have defined to get a link to the LEAFs parent
> (=CONTAINER).
> In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
> left menu the CONTAINER URL is {{...site/ContainerModule/index.html}}. The
> menu is correct and the breadcrumb wrong since it lacks the {{index.html}}
> part.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-147) link breadcrumbs to index.html instead of directory (like menus)
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136041#comment-15136041 ] Hudson commented on DOXIASITETOOLS-147: --- FAILURE: Integrated in maven-plugins #5056 (See [https://builds.apache.org/job/maven-plugins/5056/]) [MSITE-743] updated breadcrumbs URLs to be consistent with menus: point to index.html thanks to DOXIASITETOOLS-147 (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1728891]) * maven-site-plugin/src/it/inheritance-interpolation/verify.groovy > link breadcrumbs to index.html instead of directory (like menus) > > > Key: DOXIASITETOOLS-147 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-147 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Decoration model >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > see MSITE-743 > menus contain links to index.html > but breacrumbs to directory: should be consistent with menus -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-148) Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIASITETOOLS-148:
--
Fix Version/s: (was: 1.7)
> Remove SiteRenderingContext#publishDate (undo DOXIASITETOOLS-63)
>
>
> Key: DOXIASITETOOLS-148
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-148
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>
> The field {{publishDate}} has been introduced DOXIATESITETOOLS-63 but cannot
> be set anywhere. Either provide a sane setting option including proper
> documentation or drop it completely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-63) Make publish date configurable
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136045#comment-15136045
]
Michael Osipov commented on DOXIASITETOOLS-63:
--
Robert, based on our discussion in
[DOXIASITETOOLS-101|https://issues.apache.org/jira/browse/DOXIASITETOOLS-101?focusedCommentId=15070084&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15070084],
I cannot see how I can set the property {{publishDate}} on the
{{SiteRenderingContext}} thus making it superfluous. I have scheduled it for
removal in DOXIASITETOOLS-148 and MSKINS-101. I have no intention to break you
achivements but I see little use for code which cannot be called and for custom
values which are by no means documented.
> Make publish date configurable
> --
>
> Key: DOXIASITETOOLS-63
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-63
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.2
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 1.3
>
>
> When reskinning a site, the content won't change. So the publish date
> shouldn't change either.
> A lot of people relate this date to the deployment-date.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-93) request-scoped default Velocity Tools are not accessible
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136047#comment-15136047 ] Hudson commented on DOXIASITETOOLS-93: -- SUCCESS: Integrated in doxia-all #238 (See [https://builds.apache.org/job/doxia-all/238/]) [DOXIASITETOOLS-93] request-scoped default Velocity Tools are not accessible (michaelo: [http://svn.apache.org/viewvc/?view=rev&rev=1728892]) * ./doxia-sitetools/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java * ./doxia-sitetools/doxia-site-renderer/src/site/apt/index.apt.vm > request-scoped default Velocity Tools are not accessible > > > Key: DOXIASITETOOLS-93 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Michael Osipov > Fix For: 1.7 > > > only application scoped are available: $esc, ... > nut not $context, for example > see > http://svn.apache.org/viewvc/velocity/tools/tags/2.0/src/main/java/org/apache/velocity/tools/generic/tools.xml?view=markup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-106) Set language for customizable resources
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136048#comment-15136048 ] Michael Osipov commented on DOXIASITETOOLS-106: --- I think that this should be fixed in the skins. They come with the resource information. You have the locale and know in the skin whether your resource is available in your language or not. What skin should be improved? > Set language for customizable resources > --- > > Key: DOXIASITETOOLS-106 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-106 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.6 >Reporter: Eric Barboni > > This idea came from issue MSKINS-118. Because any locale you have the gif > file for google cse will allways be the english one and it may be nice to > have the possibilty to use the locale for customizing resources. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-134) Remove special handling of date format in DefaultSiteRenderer
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIASITETOOLS-134:
--
Fix Version/s: 1.7
> Remove special handling of date format in DefaultSiteRenderer
> -
>
> Key: DOXIASITETOOLS-134
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-134
> Project: Maven Doxia Sitetools
> Issue Type: Task
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 1.7
>
>
> {{dateFormat}} is double-checked from validity and existance in decoration
> model and set with a fallback when everything fails. We should solely rely on
> the decoration model because it has a fixed value. This would save code and
> duplicate fixed values. Every deviation from it is undefined behavior.
> Redudant code for example:
> {code:java}
> DateFormat dateFormat = DateFormat.getDateInstance( DateFormat.DEFAULT,
> locale );
> PublishDate publishDate =
> siteRenderingContext.getDecoration().getPublishDate();
> if ( publishDate != null && StringUtils.isNotBlank( publishDate.getFormat() )
> )
> {
> dateFormat = new SimpleDateFormat( publishDate.getFormat(), locale );
> }
> context.put( "dateFormat", dateFormat );
> {code}
> or in {{site.vm}}:
> {code}
> #if ( $decorationPublishDate && $decorationPublishDate.format )
> #set ( $format = $decorationPublishDate.format )
> #else
> #set ( $format = "-MM-dd" )
> #end
> ##
> $dateFormat.applyPattern( $format )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-99) Add typed context attribute for creationDate
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIASITETOOLS-99:
-
Fix Version/s: 1.7
> Add typed context attribute for creationDate
>
>
> Key: DOXIASITETOOLS-99
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-99
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 1.7
>
>
> Currently, we have {{dateCreation}} and {{dateRevision}} but they are
> preformatted Strings. This causes problems with HTML5 validation and meta
> tags. Moreover, skins creates would be able to use that information with a
> date formatter they want.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DOXIASITETOOLS-100) Deprecate and remove dateCreation and dateRevision
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIASITETOOLS-100:
--
Fix Version/s: 1.7
> Deprecate and remove dateCreation and dateRevision
> --
>
> Key: DOXIASITETOOLS-100
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-100
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 1.7
>
>
> Both fields are preformatted Strings and not flexible. Moreover,
> {{dateRevision}} duplicates {{currentDate}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-92) upgrade Velocity from 1.5 to 1.6.4
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136056#comment-15136056
]
Michael Osipov commented on DOXIASITETOOLS-92:
--
No we are not, I have fixed all ITs inline but one which does not make sense.
I have upgraded Doxia Sitetools to Velocity 1.7 and Maven Site Plugin to 1.7
and ran all ITs:
1. We need to remove all references to the Maven Stylus Skin in all
{{site.xml}} because we don't support it anymore. Several failed tests now pass.
2. The last remaining failing IT is {{site-jar}} which says
"File[images/h3.jpg] not found in jar archive", since neither Default nor
Fluido skin contain this file but only Stylus, we can remove this file from the
verify script and all is fine.
If you agree, I will assign this issue to be and proceed as described.
> upgrade Velocity from 1.5 to 1.6.4
> --
>
> Key: DOXIASITETOOLS-92
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-92
> Project: Maven Doxia Sitetools
> Issue Type: Wish
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Hervé Boutemy
>
> Velocity 1.5 was released in 2007:
> http://velocity.apache.org/engine/devel/changes-report.html#a1.5
> 1.6.4 was done in 2010
> http://velocity.apache.org/engine/devel/changes-report.html#a1.6.4
> I don't have precise feature in mind, just Velocity Tools 2.0 annoucement
> tells Velocity 1.6 is required (seems to work well with 1.5...):
> http://velocity.apache.org/news.html#tools20
> bq. This should be useable as a drop in replacement for Tools 1.4 or Tools
> 2.0-beta4, with a few minor exceptions. The 2.x series of VelocityTools
> requires Velocity 1.6 and JDK 1.5+.
> From a first test, actual Doxia templates work with 1.6 but not with 1.7, so
> perhaps upgrading to 1.6 is a good step before trying latest 1.7
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DOXIASITETOOLS-92) upgrade Velocity from 1.5 to 1.6.4
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136056#comment-15136056
]
Michael Osipov edited comment on DOXIASITETOOLS-92 at 2/6/16 11:41 PM:
---
No we are not, I have fixed all ITs inline but one which does not make sense.
I have upgraded Doxia Sitetools to Velocity 1.7 and Maven Site Plugin to 1.7
and ran all ITs:
1. We need to remove all references to the Maven Stylus Skin in all
{{site.xml}} because we don't support it anymore. Several failed tests now pass.
2. The last remaining failing IT is {{site-jar}} which says
"File[images/h3.jpg] not found in jar archive", since neither Default nor
Fluido skin contain this file but only Stylus, we can remove this file from the
verify script and all is fine.
If you agree, I will assign this issue to me and proceed as described.
was (Author: michael-o):
No we are not, I have fixed all ITs inline but one which does not make sense.
I have upgraded Doxia Sitetools to Velocity 1.7 and Maven Site Plugin to 1.7
and ran all ITs:
1. We need to remove all references to the Maven Stylus Skin in all
{{site.xml}} because we don't support it anymore. Several failed tests now pass.
2. The last remaining failing IT is {{site-jar}} which says
"File[images/h3.jpg] not found in jar archive", since neither Default nor
Fluido skin contain this file but only Stylus, we can remove this file from the
verify script and all is fine.
If you agree, I will assign this issue to be and proceed as described.
> upgrade Velocity from 1.5 to 1.6.4
> --
>
> Key: DOXIASITETOOLS-92
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-92
> Project: Maven Doxia Sitetools
> Issue Type: Wish
> Components: Site renderer
>Affects Versions: 1.6
>Reporter: Hervé Boutemy
>
> Velocity 1.5 was released in 2007:
> http://velocity.apache.org/engine/devel/changes-report.html#a1.5
> 1.6.4 was done in 2010
> http://velocity.apache.org/engine/devel/changes-report.html#a1.6.4
> I don't have precise feature in mind, just Velocity Tools 2.0 annoucement
> tells Velocity 1.6 is required (seems to work well with 1.5...):
> http://velocity.apache.org/news.html#tools20
> bq. This should be useable as a drop in replacement for Tools 1.4 or Tools
> 2.0-beta4, with a few minor exceptions. The 2.x series of VelocityTools
> requires Velocity 1.6 and JDK 1.5+.
> From a first test, actual Doxia templates work with 1.6 but not with 1.7, so
> perhaps upgrading to 1.6 is a good step before trying latest 1.7
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DOXIASITETOOLS-147) link breadcrumbs to index.html instead of directory (like menus)
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-147. Resolution: Fixed > link breadcrumbs to index.html instead of directory (like menus) > > > Key: DOXIASITETOOLS-147 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-147 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Decoration model >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.7 > > > see MSITE-743 > menus contain links to index.html > but breacrumbs to directory: should be consistent with menus -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-743) Automatic breadcrumbs generates URLs inconsistent with menus: should point to index.html
[
https://issues.apache.org/jira/browse/MSITE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MSITE-743.
---
Resolution: Fixed
Assignee: Hervé Boutemy
> Automatic breadcrumbs generates URLs inconsistent with menus: should point to
> index.html
>
>
> Key: MSITE-743
> URL: https://issues.apache.org/jira/browse/MSITE-743
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.4
>Reporter: Peter Bäckman
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.5
>
> Attachments: BreadcrumbBug.zip
>
>
> With a maven structure like:
> -TOP (with site.xml defining breadcrumb for TOP)
> --CONTAINER (no site.xml)
> ---LEAF (with site.xml)
>
> For the LEAF site I get a breadcrumb structure TOP - CONTAINER - LEAF.
> CONTAINER with link is automatically generated.
> I also have defined to get a link to the LEAFs parent
> (=CONTAINER).
> In the breadcrumb the CONTAINER URL is {{...site/ContainerModule}} and in the
> left menu the CONTAINER URL is {{...site/ContainerModule/index.html}}. The
> menu is correct and the breadcrumb wrong since it lacks the {{index.html}}
> part.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DOXIASITETOOLS-93) request-scoped default Velocity Tools are not accessible
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136171#comment-15136171 ] Hervé Boutemy commented on DOXIASITETOOLS-93: - great work: thank you for my understanding, I see that the new code defines specific values as properties to have better configured tools: great. But request tools were previously available in default tools.xml from Velocity: why didn't it work before? And I didn't see any unit tests that shows that now it works: did you add a test, like in http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/src/it/doxia-formats/src/site/apt/velocity-context.apt.vm ? > request-scoped default Velocity Tools are not accessible > > > Key: DOXIASITETOOLS-93 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-93 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Affects Versions: 1.6 >Reporter: Hervé Boutemy >Assignee: Michael Osipov > Fix For: 1.7 > > > only application scoped are available: $esc, ... > nut not $context, for example > see > http://svn.apache.org/viewvc/velocity/tools/tags/2.0/src/main/java/org/apache/velocity/tools/generic/tools.xml?view=markup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
