You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Incze Lajos <in...@mail.matav.hu> on 2003/01/09 02:05:05 UTC
Some issues in the HEAD
in the recent HEAD I've found some issues:
1. The 'genapp' goal doesn't work because the
"src/**" pattern is excluded from the
resources in it's POM. Clearly., it needs
the src directory to be able to run.
2. $MAVEN_HOME/maven-project.xsd should be
updated, e.g. this is bad:
<xs:element name="resources">
<xs:complexType>
<xs:sequence>
<xs:element ref="includes" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="excludes" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
so pom:validate barfs if 'resources' have
resource child.
3. The 'site:deploy' goal deploys the whole
target directory, not just docs, because
the 'maven.docs.dest' property is not set.
4. The xdoc:transform goal can't cope with
the <source> tag, it'll be trimmed (i.e.
whitespace sequences are replaced by
a single space everywhere).
5. The xdoc:transform tag drops subdirectory
navigation.xml files (so subitems are not
expanded on click).
6. 'xdoc:validate' stops with message:
INTERNAL ERROR
Reference made to goal 'pom:taglib' which has no definition.
even if I use it to the maven xdocs.
I know that am indicating all these things
well in the middle of a refactoring effort.
But doesn't hurt, I suppose. (Even the
'genapp' bug was clearly the result of the
refactoring, as well the 'xdoc' sickness.)
Thanks
incze
Re: Some issues in the HEAD
Posted by Incze Lajos <in...@mail.matav.hu>.
On Sun, Jan 19, 2003 at 10:36:32PM +1100, dion@multitask.com.au wrote:
> Incze Lajos <in...@mail.matav.hu> wrote on 16/01/2003 03:41:09 PM:
> [snippage]
>
> > My earlier patch was partial, as one of the availability lookups is
> > superfluos:
> >
> > util:available file="${maven.docs.src}/navigation.xml is the same as
> > util:available file="${file.parentFile.absoluteFile}/navigation.xml when
> > the current dir is maven.docs.src.
>
> Yes, but ONLY when the current file being processed is in the top level of
> the xdocs directory. The way it is also allows lower levels to specify a
> nav file.
>
> > Has this all sense?
> Does my answer above explain it?
Yes, I was wrong about that. Thanks.
incze
About dependency types (affects such bugs as MAVEN 196 and 197)
Posted by Tim Stephenson <ti...@thestephensons.me.uk>.
I have also had some problems in using ejb and war artifacts due to the
dependency 'type' tag and read with interest the discussion of the
ArtifactFactory.
Now I am not familiar with the internals of maven, so forgive me if I am
overlooking some things, but it seems the process of downloading correct
jars at least should be achievable as a plugin. The following jelly script
seems to do it pretty well in fact.
<goal name="maven:prepare-local-repository"
description="Compensate for the maven bug that fails to download
non-jar artifacts">
<u:tokenize var="listOfRepoRemote" delim=",
">${maven.repo.remote}</u:tokenize>
<j:forEach var="repo" items="${listOfRepoRemote}">
<j:forEach var="dep" items="${pom.dependencies.iterator()}">
<j:set var="artifactType" value="${dep.getType()}"/>
<j:if test="${empty(artifactType)}">
<j:set var="artifactType" value="jar"/>
</j:if>
<mkdir
dir="${maven.home}/repository/${dep.getProjectId()}/${artifactType}s"/>
<get
src="${repo}/${dep.getProjectId()}/${artifactType}s/${dep.getProjectId()}-${
dep.getVersion()}.${artifactType}"
dest="${maven.home}/repository/${dep.getProjectId()}/${artifactType}s/${dep.
getProjectId()}-${dep.getVersion()}.${artifactType}"
verbose="true"
usetimestamp="true"
ignoreerrors="true"/>
</j:forEach>
</j:forEach>
</goal>
If this was made a very early dependency for maven 'sessions' then I would
think all the plugins that depend on non-jar artifacts should find them
exactly where they expect by the time they run.
I took the liberty of naming this goal in the maven namespace, but hopefully
it can find a home somewhere?
Tim
Re: Some issues in the HEAD
Posted by di...@multitask.com.au.
Incze Lajos <in...@mail.matav.hu> wrote on 16/01/2003 03:41:09 PM:
[snippage]
> My earlier patch was partial, as one of the availability lookups is
> superfluos:
>
> util:available file="${maven.docs.src}/navigation.xml is the same as
> util:available file="${file.parentFile.absoluteFile}/navigation.xml when
> the current dir is maven.docs.src.
Yes, but ONLY when the current file being processed is in the top level of
the xdocs directory. The way it is also allows lower levels to specify a
nav file.
> Has this all sense?
Does my answer above explain it?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: Some issues in the HEAD
Posted by Incze Lajos <in...@mail.matav.hu>.
On Thu, Jan 16, 2003 at 01:51:10PM +1100, dion@multitask.com.au wrote:
> Incze,
>
> what is the correct ordering for the navigation.xml files in your opinion?
> The patch you provide puts the subdir nav files as overriding generated
> ones. Is that what you want?
>
I think that if somebody uses a single igenerated sitewide navigation.xml file
the he/she won't have navigation files in the source tree. As I see
this sequence has the only purpose to find a navigation file if the current
directory don't have one. So, I think, the hand edited in-place navigation
file should have allways priority over the generated (the same way as if
I put a navigation.xml into a subdir, it will be applied over the root
navigation file.) If someone uses generated navigation then should
purge out all the nav files from the xdocs source tree.
My earlier patch was partial, as one of the availability lookups is superfluos:
util:available file="${maven.docs.src}/navigation.xml is the same as
util:available file="${file.parentFile.absoluteFile}/navigation.xml when
the current dir is maven.docs.src.
Has this all sense?
incze
Re: Some issues in the HEAD
Posted by di...@multitask.com.au.
Incze,
what is the correct ordering for the navigation.xml files in your opinion?
The patch you provide puts the subdir nav files as overriding generated
ones. Is that what you want?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Incze Lajos <in...@mail.matav.hu> wrote on 16/01/2003 12:36:35 PM:
> > 5. The xdoc:transform tag drops subdirectory
> > navigation.xml files (so subitems are not
> > expanded on click).
> >
>
> This seems to be a little ordering problem in plugin.jelly. The
> subdirectory navigation file is ovewritten altough it was found.
>
> incze
> [attachment "patch.txt" deleted by dIon Gillard/Multitask Consulting/AU]
--
> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-maven-dev-
> help@jakarta.apache.org>
> ForwardSourceID:NT000A3762
Re: Some issues in the HEAD
Posted by Incze Lajos <in...@mail.matav.hu>.
> 5. The xdoc:transform tag drops subdirectory
> navigation.xml files (so subitems are not
> expanded on click).
>
This seems to be a little ordering problem in plugin.jelly. The
subdirectory navigation file is ovewritten altough it was found.
incze
Re: Some issues in the HEAD
Posted by di...@multitask.com.au.
Applied, thanks.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Incze Lajos <in...@mail.matav.hu> wrote on 16/01/2003 11:50:01 AM:
> On Thu, Jan 16, 2003 at 01:12:31AM +0100, Incze Lajos wrote:
> > > 4. The xdoc:transform goal can't cope with
> > > the <source> tag, it'll be trimmed (i.e.
> > > whitespace sequences are replaced by
> > > a single space everywhere).
> > >
> >
> > Digging into the plugin script I experienced, that changing these
lines
> >
>
> ... etc.
>
> Yet another patch to make formatting happy.
>
> incze
> ---
>
>
>
> --- src/plugins-build/xdoc/site.jsl.old 2003-01-16 01:43:46.000000000
+0100
> +++ src/plugins-build/xdoc/site.jsl 2003-01-16 01:44:11.000000000
+0100
> @@ -430,9 +430,7 @@
>
> <jsl:template match="source" trim="false">
> <div id="source">
> - <pre>
> - <x:expr select="."/>
> - </pre>
> + <pre><x:expr select="."/></pre>
> </div>
> </jsl:template>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-maven-dev-
> help@jakarta.apache.org>
>
> ForwardSourceID:NT000A36EE
Re: Some issues in the HEAD
Posted by Incze Lajos <in...@mail.matav.hu>.
On Thu, Jan 16, 2003 at 01:12:31AM +0100, Incze Lajos wrote:
> > 4. The xdoc:transform goal can't cope with
> > the <source> tag, it'll be trimmed (i.e.
> > whitespace sequences are replaced by
> > a single space everywhere).
> >
>
> Digging into the plugin script I experienced, that changing these lines
>
... etc.
Yet another patch to make formatting happy.
incze
---
--- src/plugins-build/xdoc/site.jsl.old 2003-01-16 01:43:46.000000000 +0100
+++ src/plugins-build/xdoc/site.jsl 2003-01-16 01:44:11.000000000 +0100
@@ -430,9 +430,7 @@
<jsl:template match="source" trim="false">
<div id="source">
- <pre>
- <x:expr select="."/>
- </pre>
+ <pre><x:expr select="."/></pre>
</div>
</jsl:template>
Re: Some issues in the HEAD
Posted by Incze Lajos <in...@mail.matav.hu>.
> 4. The xdoc:transform goal can't cope with
> the <source> tag, it'll be trimmed (i.e.
> whitespace sequences are replaced by
> a single space everywhere).
>
Digging into the plugin script I experienced, that changing these lines
--- src/plugins-build/xdoc/plugin.jelly.old 2003-01-16 01:08:22.000000000 +0100
+++ src/plugins-build/xdoc/plugin.jelly 2003-01-16 01:08:33.000000000 +0100
@@ -169,8 +169,8 @@
<x:parse var="doc" xml="${file}"/>
<j:file name="${outFile}" encoding="${outputencoding}"
- omitXmlDeclaration="true" outputMode="html"
- prettyPrint="yes">
+ omitXmlDeclaration="true" outputMode="xml"
+ prettyPrint="no">
<j:include uri="${stylesheet.toString()}"/>
</j:file>
</j:forEach>
(i.e. output mode to xml and pretty printing switched off) did cure the
problem with the <source> tag. In fact, I don't understand why, would anybody
set the jsl input to html, not xml, and thought that pretty printing
would destroy formatting in source tag.
Please, check if I was right, or not.
incze
Re: Some issues in the HEAD
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-01-08 at 20:05, Incze Lajos wrote:
> in the recent HEAD I've found some issues:
>
> 1. The 'genapp' goal doesn't work because the
> "src/**" pattern is excluded from the
> resources in it's POM. Clearly., it needs
> the src directory to be able to run.
Fixed this one as it's easy and I will tackle the rest as soon as I can
if someone else doesn't beat me to it.
Thanks for hunting.
> 2. $MAVEN_HOME/maven-project.xsd should be
> updated, e.g. this is bad:
>
> <xs:element name="resources">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="includes" minOccurs="0" maxOccurs="unbounded"/>
> <xs:element ref="excludes" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> so pom:validate barfs if 'resources' have
> resource child.
>
> 3. The 'site:deploy' goal deploys the whole
> target directory, not just docs, because
> the 'maven.docs.dest' property is not set.
>
> 4. The xdoc:transform goal can't cope with
> the <source> tag, it'll be trimmed (i.e.
> whitespace sequences are replaced by
> a single space everywhere).
>
> 5. The xdoc:transform tag drops subdirectory
> navigation.xml files (so subitems are not
> expanded on click).
>
> 6. 'xdoc:validate' stops with message:
>
> INTERNAL ERROR
> Reference made to goal 'pom:taglib' which has no definition.
>
> even if I use it to the maven xdocs.
>
> I know that am indicating all these things
> well in the middle of a refactoring effort.
> But doesn't hurt, I suppose. (Even the
> 'genapp' bug was clearly the result of the
> refactoring, as well the 'xdoc' sickness.)
>
> Thanks
>
> incze
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society