[jira] Commented: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169611#action_169611
]
Jason Chaffee commented on MARTIFACT-35:
Ok, this is the dialogue I was hoping for. :)
Again, I fully understand not wanting to allow arbitrary version schemes...I
really do. I have even tried to convince the powers to be use the current
maven versioning system. However, sometimes it is very hard to convince people
it is the right way to go as they are "stuck" in what they are used to and have
known. However, it is much easier to convince them to use OSGI or a standard
like that as they already trying to get their particular industry to move
towards OSGI. Therefore, if maven moves to using a documented standard
versioning nomenclature I think that will solve their problem.
> Allow the ability to "plugin" or "inject" different versioning implementations
> --
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
>
> 1
> 2
> 1
> ${project.build.number}
> .
>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169607#action_169607
]
Jason van Zyl commented on MARTIFACT-35:
Mercury allows for any implementation, but Mercury is not Maven. Mercury was
designed to support any arbitrary system. That does not mean we want to allow
these arbitrary capabilities in Maven. In fact we don't. Allowing arbitrary
version schemes requires a lot of work in Maven to support. Everything would
need to support it and your clients need to really understand the real cost of
wanting something different. I ardently believe that we don't need N version
systems. One decent one like OSGi is a good start and we can help improve that
one.
> Allow the ability to "plugin" or "inject" different versioning implementations
> --
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
>
> 1
> 2
> 1
> ${project.build.number}
> .
>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169606#action_169606
]
Jason Chaffee commented on MARTIFACT-35:
I can understand where you are coming from that you might end up having to
support it, but couldn't this simply be a product of a good API and
implementation that allows users to take the code and inject their own
implementation? Maybe what I am asking for more than anything is an easy way
to "fix" the code to enable this, because it is anything but easy to do with
the 2.x implementation. Maybe mercury will allow for this? I don't know.
Also, perhaps my ideas/comments in the original comment are not the correct way
to go about ultimately supporting this, but I was hoping by filing an issue it
would create some dialogue.
I will try to figure it out on my own.
> Allow the ability to "plugin" or "inject" different versioning implementations
> --
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
>
> 1
> 2
> 1
> ${project.build.number}
> .
>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169604#action_169604
]
Jason van Zyl commented on MARTIFACT-35:
It was already discussed on the list. And I would -1 anyone trying to allow
this type of variant. We will end up having to maintain it and all the problems
with interactions between different projects that have incommensurate schemes.
You have the source code so you can "fix" whatever you need to and you can
support it.
> Allow the ability to "plugin" or "inject" different versioning implementations
> --
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
>
> 1
> 2
> 1
> ${project.build.number}
> .
>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169603#action_169603
]
Jason Chaffee commented on MARTIFACT-35:
I wasn't suggesting supporting N variants. I was suggesting allowing users the
ability to supply their own variant. Maven would only have to support their
own variant. Basically, I am suggesting a better design/API that allows a
company to inject their own implementation without the internal workings of
maven dependent on what the actual format is. This is simply good engineering.
Also, why close the but so quickly...since it has only been a matter of minutes
no one else will have the chance to see it, vote on it, or make their own
judgements if it is worth while.
This contributes to the feeling that the maven team isn't really listening to
the users and what they really want in a build system. This request isn't
personally coming from me, but from two different companies that have asked me
to "fix" maven's versioning system because it simply does not work for them and
they cannot change the way they do it for certain reasons.
> Allow the ability to "plugin" or "inject" different versioning implementations
> --
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
>
> 1
> 2
> 1
> ${project.build.number}
> .
>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
[
http://jira.codehaus.org/browse/MARTIFACT-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MARTIFACT-35.
--
Resolution: Won't Fix
We will gravitate toward a single standard. We don't need to support N variants.
> Allow the ability to "plugin" or "inject" different versioning implementations
> --
>
> Key: MARTIFACT-35
> URL: http://jira.codehaus.org/browse/MARTIFACT-35
> Project: Maven Artifact
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Jason Chaffee
>
> Currently, maven's versioning for snapshot builds is
> ${timestamp}-${build.number}. However, it is often the case that companies
> have their own versioning requirements or conventions and there are different
> models for versioning such as OSGI, etc. For example, eclipse plugin
> versioning proposal has the following:
> the major segment indicates breakage in the API
> the minor segment indicates "externally visible" changes
> the service segment indicates bug fixes and the change of development stream
> the qualifier segment indicates a particular build
> This may result their snapshot builds take the the form of 1.2.1.v20050506 or
> 1.2.1.34 depending on they wanted to represent the qualifier segment. They
> could use the timestamp in the form "v20050506" or they could use a build
> number "34".
> Also, many times companies would like to utilize the build number in the
> final release version. For example, 1.2.1-SNAPSHOT is on build 34 when a
> release is done. Instead of making the final artifact 1.2.1, they may wish
> to make the final artifact 1.2.1.34 or 1.2.1-34.
> I think it would be ok for maven to only actually implement their default
> strategy, but I think allowing a different implementation to be injected
> based on the user's needs would be extremely valuable.
> Another option is change the way works in the pom. Instead of
> entering a string, perhaps it could have child elements such as the following:
>
> 1
> 2
> 1
> ${project.build.number}
> .
>
> Note: qualifer may be the same notion as classifier. However, it would be
> nice to be able to specify to use a "." or a "-" or a "_" separator based on
> whatever format your company abides by.
--
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: (MARTIFACT-35) Allow the ability to "plugin" or "inject" different versioning implementations
Allow the ability to "plugin" or "inject" different versioning implementations
--
Key: MARTIFACT-35
URL: http://jira.codehaus.org/browse/MARTIFACT-35
Project: Maven Artifact
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Jason Chaffee
Currently, maven's versioning for snapshot builds is
${timestamp}-${build.number}. However, it is often the case that companies
have their own versioning requirements or conventions and there are different
models for versioning such as OSGI, etc. For example, eclipse plugin
versioning proposal has the following:
the major segment indicates breakage in the API
the minor segment indicates "externally visible" changes
the service segment indicates bug fixes and the change of development stream
the qualifier segment indicates a particular build
This may result their snapshot builds take the the form of 1.2.1.v20050506 or
1.2.1.34 depending on they wanted to represent the qualifier segment. They
could use the timestamp in the form "v20050506" or they could use a build
number "34".
Also, many times companies would like to utilize the build number in the final
release version. For example, 1.2.1-SNAPSHOT is on build 34 when a release is
done. Instead of making the final artifact 1.2.1, they may wish to make the
final artifact 1.2.1.34 or 1.2.1-34.
I think it would be ok for maven to only actually implement their default
strategy, but I think allowing a different implementation to be injected based
on the user's needs would be extremely valuable.
Another option is change the way works in the pom. Instead of
entering a string, perhaps it could have child elements such as the following:
1
2
1
${project.build.number}
.
Note: qualifer may be the same notion as classifier. However, it would be nice
to be able to specify to use a "." or a "-" or a "_" separator based on
whatever format your company abides by.
--
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: (DOXIA-301) Invalid interpretation of links' aliases in tables.
[ http://jira.codehaus.org/browse/DOXIA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kornel updated DOXIA-301: - Attachment: MNG-301-module-confluence.patch This path solves this issue. > Invalid interpretation of links' aliases in tables. > --- > > Key: DOXIA-301 > URL: http://jira.codehaus.org/browse/DOXIA-301 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel > Attachments: MNG-301-module-confluence.patch > > > For example in the following table: > || Version || Download || Format || > |0.1.1 | [Download|http://example.com/release.0.1.1/ex-win32-win32.x86.zip] | > 12-12-2008 | zip | > |0.1.2 | [Download|http://example.com/release.0.1.2/ex-win32-win32.x86.zip] | > 04-12-2008 | zip | > |0.1.3 | [Download|http://example.com/release.0.1.3/ex-win32-win32.x86.zip] | > 03-11-2008 | zip | > '|' characters in the links are interpreted as new table's cells. -- 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: (DOXIA-301) Invalid interpretation of links' aliases in tables.
Invalid interpretation of links' aliases in tables. --- Key: DOXIA-301 URL: http://jira.codehaus.org/browse/DOXIA-301 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel For example in the following table: || Version || Download || Format || |0.1.1 | [Download|http://example.com/release.0.1.1/ex-win32-win32.x86.zip] | 12-12-2008 | zip | |0.1.2 | [Download|http://example.com/release.0.1.2/ex-win32-win32.x86.zip] | 04-12-2008 | zip | |0.1.3 | [Download|http://example.com/release.0.1.3/ex-win32-win32.x86.zip] | 03-11-2008 | zip | '|' characters in the links are interpreted as new table's cells. -- 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] Issue Comment Edited: (DOXIA-299) Text formatting in sections does not work.
[ http://jira.codehaus.org/browse/DOXIA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169468#action_169468 ] Kornel edited comment on DOXIA-299 at 3/14/09 6:13 PM: --- This path solves this issue better than the first path, because it does not generate paragraph tags. was (Author: kornelsk): This path solves this issue. > Text formatting in sections does not work. > -- > > Key: DOXIA-299 > URL: http://jira.codehaus.org/browse/DOXIA-299 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel > Attachments: MNG-299-module-confluence.patch, > MNG-299-module-confluence.patch > > > For example: > h3. Menu _Diagram_ > does not 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] Updated: (DOXIA-299) Text formatting in sections does not work.
[ http://jira.codehaus.org/browse/DOXIA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kornel updated DOXIA-299: - Attachment: MNG-299-module-confluence.patch This path solves this issue. > Text formatting in sections does not work. > -- > > Key: DOXIA-299 > URL: http://jira.codehaus.org/browse/DOXIA-299 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel > Attachments: MNG-299-module-confluence.patch, > MNG-299-module-confluence.patch > > > For example: > h3. Menu _Diagram_ > does not 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: (DOXIA-300) Bold markup on start of a document does not work.
Bold markup on start of a document does not work. - Key: DOXIA-300 URL: http://jira.codehaus.org/browse/DOXIA-300 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel Attachments: MNG-300-module-confluence.patch For example in a document that begins with the following line: *Welcome* "*Welcome*" will be parsed as a list not as a bold text. -- 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: (DOXIA-300) Bold markup on start of a document does not work.
[ http://jira.codehaus.org/browse/DOXIA-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kornel updated DOXIA-300: - Attachment: MNG-300-module-confluence.patch Path, that solves this issue. > Bold markup on start of a document does not work. > - > > Key: DOXIA-300 > URL: http://jira.codehaus.org/browse/DOXIA-300 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel > Attachments: MNG-300-module-confluence.patch > > > For example in a document that begins with the following line: > *Welcome* > "*Welcome*" will be parsed as a list not as a bold text. -- 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: (DOXIA-299) Text formatting in sections does not work.
[ http://jira.codehaus.org/browse/DOXIA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kornel updated DOXIA-299: - Attachment: MNG-299-module-confluence.patch Path solves this issue. > Text formatting in sections does not work. > -- > > Key: DOXIA-299 > URL: http://jira.codehaus.org/browse/DOXIA-299 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel > Attachments: MNG-299-module-confluence.patch > > > For example: > h3. Menu _Diagram_ > does not 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: (DOXIA-299) Text formatting in sections does not work.
Text formatting in sections does not work. -- Key: DOXIA-299 URL: http://jira.codehaus.org/browse/DOXIA-299 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel For example: h3. Menu _Diagram_ does not 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] Issue Comment Edited: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[
http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169440#action_169440
]
Olivier Lamy edited comment on SCM-262 at 3/14/09 4:16 PM:
---
My proposal is to use :
{code}
svn copy --file /tmp/maven-scm-297444897.commit -r 599
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
{code}
BTW to preserve backward comp this won't be the default way, it will be
activated though an option.
I propose to add a new method in ScmProvider :
{code:java}
TagScmResult tag( ScmRepository repository, ScmFileSet fileSet, String
tagName, TagParameters tagParameters)
throws ScmException;
{code}
{code:title=TagParameters.java|borderStyle=solid}
String message;
boolean remoteTagging = false;
String scmRevision;
{code}
In the new tag method :
{code}
// really pseudo code but maven style :-)
if (!remoteTagging)
{
use current tag command
}
if (remoteTagging && scmRevision != null)
{
// this can be usefull to tag a particular svn rev (ie releasing one build in
ci tools)
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
if (remoteTagging && scmRevision == null)
{
get the current svn with SvnInfoCommandResult;
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
{code}
If no comments/objections I will implements this as it
BTW :
* we will have to add some new mojo parameters in the maven-release-plugin to
be able to use in the release plugin
* others scm implementations will use their current Tag command (if remote tag
is configured a warning will say "this scm implementation doesn't support
remote tagging"$
was (Author: olamy):
My proposal is to use :
{code}
svn copy --file /tmp/maven-scm-297444897.commit -r 599
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
{code}
BTW to preserve backward comp this won't be the default way, it will be
activated though an option.
I propose to add a new method in ScmProvider :
{code:java}
TagScmResult tag( ScmRepository repository, ScmFileSet fileSet, String
tagName, TagParameters tagParameters)
throws ScmException;
{code}
{code:title=TagParameters.java|borderStyle=solid}
String message;
String remoteTagging = false;
String scmRevision;
{code}
In the new tag method :
{code}
// really pseudo code but maven style :-)
if (!remoteTagging)
{
use current tag command
}
if (remoteTagging && scmRevision != null)
{
// this can be usefull to tag a particular svn rev (ie releasing one build in
ci tools)
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
if (remoteTagging && scmRevision == null)
{
get the current svn with SvnInfoCommandResult;
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
{code}
If no comments/objections I will implements this as it
BTW :
* we will have to add some new mojo parameters in the maven-release-plugin to
be able to use in the release plugin
* others scm implementations will use their current Tag command (if remote tag
is configured a warning will say "this scm implementation doesn't support
remote tagging"$
> scm:tag for subversion tagging from local version of code, not directly from
> repository
> ---
>
> Key: SCM-262
> URL: http://jira.codehaus.org/browse/SCM-262
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Reporter: Stephan Heilner
>Assignee: Olivier Lamy
> Fix For: 1.1.1
>
> Attachments: SvnTagCommand.patch
>
>
> In theory, you shouldn't tag or branch from a local and potentially different
> version of the code. From what I can tell, the scm:tag imports your existing
> code into a new tag. With subversion, tagging is very lightweight if you do
> a 'svn copy trunk_url tag_url'. The way it currently works make sense for
> other repositories such as CVS but not for subversion.
--
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: (DOXIA-232) Nested list parsing is not generating correct events
[
http://jira.codehaus.org/browse/DOXIA-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kornel updated DOXIA-232:
-
Attachment: MNG-232-module-confluence.patch
Path solves this issue.
> Nested list parsing is not generating correct events
>
>
> Key: DOXIA-232
> URL: http://jira.codehaus.org/browse/DOXIA-232
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Confluence
>Affects Versions: 1.0-alpha-10
>Reporter: Vincent Massol
> Attachments: MNG-232-module-confluence.patch, nested_lists.zip
>
>
> Here's some input I've used (verified it works in Confluence):
> {noformat}
> # Item 1
> ## Item 2
> ##* Item 3
> ## Item 4
> # Item 5
> * Item 1
> ** Item 2
> *** Item 3
> ** Item 4
> * Item 5
> * Item 6
> {noformat}
> This generates the following events: NL, LI, NL, LI, LI_, LI, LI_, LI, LI_,
> NL_, LI_, etc
> It should have generated: NL, LI, NL, LI, LIST, LI, LI_, LIST_, LI_, etc
--
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-3732) [regression] project.getActiveProfiles() has not the same behaviour
[ http://jira.codehaus.org/browse/MNG-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3732: --- Attachment: MNG-3732.patch Proposed patch, please review Shane. > [regression] project.getActiveProfiles() has not the same behaviour > --- > > Key: MNG-3732 > URL: http://jira.codehaus.org/browse/MNG-3732 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0-alpha-1 >Reporter: Vincent Siveton > Fix For: 3.0-alpha-3 > > Attachments: MNG-3732.patch > > > See MPH-38 -- 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: (DOXIA-298) Problem with relative links
[ http://jira.codehaus.org/browse/DOXIA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kornel updated DOXIA-298: - Attachment: MNG-298-module-confluence.patch This is path, that solves this issue. > Problem with relative links > --- > > Key: DOXIA-298 > URL: http://jira.codehaus.org/browse/DOXIA-298 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Confluence >Affects Versions: 1.1 >Reporter: Kornel > Attachments: MNG-298-module-confluence.patch > > > Relative links, for example [Overview|overview/index] are not generated > correctly. -- 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: (DOXIA-298) Problem with relative links
Problem with relative links --- Key: DOXIA-298 URL: http://jira.codehaus.org/browse/DOXIA-298 Project: Maven Doxia Issue Type: Improvement Components: Module - Confluence Affects Versions: 1.1 Reporter: Kornel Relative links, for example [Overview|overview/index] are not generated correctly. -- 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-406) scm tag does not work with Subversion 1.5.1
[
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169447#action_169447
]
Stephen Connolly commented on SCM-406:
--
There are some reports I saw a month back on the subversion mailing list that
this is an issue with the neon transport. If you use the serf transport the
problem goes away.
AFAIK the situation is as follows:
svn:// always works
svn+ssh:// always works
http:// only works with serf (I have not confirmed this yet)
https:// only works with serf (I have not confirmed this yet)
> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error
> occurs:
> {code}
> svn: File
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
> already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.
--
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: (MRESOURCES-84) targetPath no longer relative
[
http://jira.codehaus.org/browse/MRESOURCES-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MRESOURCES-84.
---
Assignee: Benjamin Bentmann
Resolution: Not A Bug
A path with a leading slash "/" is not a relative path. Either omit the
{{}} or set it to a dot "." only.
> targetPath no longer relative
> -
>
> Key: MRESOURCES-84
> URL: http://jira.codehaus.org/browse/MRESOURCES-84
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Nic Grounds
>Assignee: Benjamin Bentmann
>
> My POMs used to specify "/" as the output directory (targetPath) for
> resources (i.e. ...
> / ...) However, with Maven 2.0.10 (i.e.
> maven-resources-plugin 2.3) the targetPath is apparently not treated as
> relative to the build output directory.
> The Maven POM reference (http://maven.apache.org/pom.html#Build) says the
> default should be the base directory (and indeed not specifying a targetPath
> defaults to the correct place).
> However the Maven Model documentation
> (http://maven.apache.org/ref/current/maven-model/maven.html#class_resource)
> claims that targetPath is "relative to the target/classes directory (i.e.
> ${project.build.outputDirectory})"
> Given a / entry I get the following:
> [INFO] [resources:resources]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 39 resources to /
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] /com/blah/blah/blah/my-resource-file (No such file or directory)
--
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] Issue Comment Edited: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[
http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169440#action_169440
]
Olivier Lamy edited comment on SCM-262 at 3/14/09 12:10 PM:
My proposal is to use :
{code}
svn copy --file /tmp/maven-scm-297444897.commit -r 599
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
{code}
BTW to preserve backward comp this won't be the default way, it will be
activated though an option.
I propose to add a new method in ScmProvider :
{code:java}
TagScmResult tag( ScmRepository repository, ScmFileSet fileSet, String
tagName, TagParameters tagParameters)
throws ScmException;
{code}
{code:title=TagParameters.java|borderStyle=solid}
String message;
String remoteTagging = false;
String scmRevision;
{code}
In the new tag method :
{code}
// really pseudo code but maven style :-)
if (!remoteTagging)
{
use current tag command
}
if (remoteTagging && scmRevision != null)
{
// this can be usefull to tag a particular svn rev (ie releasing one build in
ci tools)
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
if (remoteTagging && scmRevision == null)
{
get the current svn with SvnInfoCommandResult;
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
{code}
If no comments/objections I will implements this as it
BTW :
* we will have to add some new mojo parameters in the maven-release-plugin to
be able to use in the release plugin
* others scm implementations will use their current Tag command (if remote tag
is configured a warning will say "this scm implementation doesn't support
remote tagging"$
was (Author: olamy):
My proposal is to use :
{code}
svn copy --file /tmp/maven-scm-297444897.commit -r 599
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
{code}
BTW to preserve backward comp this won't be the default way, it will be
activated though an option.
I propose to add a new method in ScmProvider :
{code:java}
TagScmResult tag( ScmRepository repository, ScmFileSet fileSet, String
tagName, TagParameters tagParameters)
throws ScmException;
{code}
{code:title=TagParameters.java|borderStyle=solid}
String message;
String remoteTagging = false;
String scmRevision;
{code}
In the new tag method :
{code}
// really pseudo code but maven style :-)
if (!remoteTagging)
{
use current tag command
}
if (remoteTagging && scmRevision != null)
{
// this can be usefull to tag a particular svn rev (ie releasing one build in
ci tools)
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
if (remoteTagging && scmRevision == null)
{
get the current svn with SvnInfoCommandResult;
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
{code}
If no comments/objections I will implements this as it
BTW we will have to add some new mojo parameters in the maven-release-plugin to
be able to use in the release plugin
> scm:tag for subversion tagging from local version of code, not directly from
> repository
> ---
>
> Key: SCM-262
> URL: http://jira.codehaus.org/browse/SCM-262
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Reporter: Stephan Heilner
>Assignee: Olivier Lamy
> Fix For: 1.1.1
>
> Attachments: SvnTagCommand.patch
>
>
> In theory, you shouldn't tag or branch from a local and potentially different
> version of the code. From what I can tell, the scm:tag imports your existing
> code into a new tag. With subversion, tagging is very lightweight if you do
> a 'svn copy trunk_url tag_url'. The way it currently works make sense for
> other repositories such as CVS but not for subversion.
--
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-262) scm:tag for subversion tagging from local version of code, not directly from repository
[
http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169440#action_169440
]
Olivier Lamy commented on SCM-262:
--
My proposal is to use :
{code}
svn copy --file /tmp/maven-scm-297444897.commit -r 599
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
{code}
BTW to preserve backward comp this won't be the default way, it will be
activated though an option.
I propose to add a new method in ScmProvider :
{code:java}
TagScmResult tag( ScmRepository repository, ScmFileSet fileSet, String
tagName, TagParameters tagParameters)
throws ScmException;
{code}
{code:title=TagParameters.java|borderStyle=solid}
String message;
String remoteTagging = false;
String scmRevision;
{code}
In the new tag method :
{code}
// really pseudo code but maven style :-)
if (!remoteTagging)
{
use current tag command
}
if (remoteTagging && scmRevision != null)
{
// this can be usefull to tag a particular svn rev (ie releasing one build in
ci tools)
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
if (remoteTagging && scmRevision == null)
{
get the current svn with SvnInfoCommandResult;
svn copy --file /tmp/maven-scm-297444897.commit -r ${scmRevision}
http://XXX/svn/project/trunk http://XXX/svn/project/tags/foo-1.0.0
}
{code}
If no comments/objections I will implements this as it
BTW we will have to add some new mojo parameters in the maven-release-plugin to
be able to use in the release plugin
> scm:tag for subversion tagging from local version of code, not directly from
> repository
> ---
>
> Key: SCM-262
> URL: http://jira.codehaus.org/browse/SCM-262
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Reporter: Stephan Heilner
>Assignee: Olivier Lamy
> Fix For: 1.1.1
>
> Attachments: SvnTagCommand.patch
>
>
> In theory, you shouldn't tag or branch from a local and potentially different
> version of the code. From what I can tell, the scm:tag imports your existing
> code into a new tag. With subversion, tagging is very lightweight if you do
> a 'svn copy trunk_url tag_url'. The way it currently works make sense for
> other repositories such as CVS but not for subversion.
--
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: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-262: - Assignee: Olivier Lamy Fix Version/s: (was: future) 1.1.1 > scm:tag for subversion tagging from local version of code, not directly from > repository > --- > > Key: SCM-262 > URL: http://jira.codehaus.org/browse/SCM-262 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Stephan Heilner >Assignee: Olivier Lamy > Fix For: 1.1.1 > > Attachments: SvnTagCommand.patch > > > In theory, you shouldn't tag or branch from a local and potentially different > version of the code. From what I can tell, the scm:tag imports your existing > code into a new tag. With subversion, tagging is very lightweight if you do > a 'svn copy trunk_url tag_url'. The way it currently works make sense for > other repositories such as CVS but not for subversion. -- 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: (MERCURY-102) Review and possibly polish logging
[ http://jira.codehaus.org/browse/MERCURY-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-102. Resolution: Fixed Fix Version/s: 1.0-alpha-6 Adjusted INFO level to only show relevant info > Review and possibly polish logging > -- > > Key: MERCURY-102 > URL: http://jira.codehaus.org/browse/MERCURY-102 > Project: Mercury > Issue Type: Task > Components: Ant tasks, Transport >Affects Versions: 1.0-alpha-6 >Reporter: Benjamin Bentmann >Assignee: Oleg Gusakov >Priority: Trivial > Fix For: 1.0-alpha-6 > > Attachments: mercury.log > > > The attached log snippet was produced by running the Maven core bootstrap > using the Mercury Ant Tasks. The logging is a little too verbose on its > current levels, i.e. dumping the HTML error pages from the server at warn. -- 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: (MERCURY-101) adjust logging to only show downloaded files on INFO level
[ http://jira.codehaus.org/browse/MERCURY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-101. Resolution: Duplicate Fix Version/s: 1.0-alpha-6 of 102 > adjust logging to only show downloaded files on INFO level > -- > > Key: MERCURY-101 > URL: http://jira.codehaus.org/browse/MERCURY-101 > Project: Mercury > Issue Type: Improvement > Components: Repository >Affects Versions: 1.0-alpha-6 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 1.0-alpha-6 > > -- 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: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-317: - Fix Version/s: (was: 1.1.1) 1.2 > Add edit and unedit commands > > > Key: SCM-317 > URL: http://jira.codehaus.org/browse/SCM-317 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-cvs >Reporter: Emmanuel Venisse >Assignee: Olivier Lamy > Fix For: 1.2 > > Attachments: provider-cvs-with-edit.patch > > -- 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-391) site:state creates wrong links for menu items
[ http://jira.codehaus.org/browse/MSITE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169399#action_169399 ] Hugo Palma commented on MSITE-391: -- Another thing i've found out is that if i revert to version 2.0-beta-5 of the site plugin the links are generated fine on both windows and linux machines. Any version after that generates broken links on linux. So it seems that a change committed first on beta-6 broke the link generation on linux. > site:state creates wrong links for menu items > - > > Key: MSITE-391 > URL: http://jira.codehaus.org/browse/MSITE-391 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Hugo Palma > Attachments: test-case.zip > > > I'm attaching a test case where if you run the site:stage goal it will > generate wrong links on the left menu. The links will actually point to the > root site directory when they should point the the pages i provided in the > href attribute in my site.xml descriptor file. -- 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
