[jira] Created: (MRELEASE-395) release:stage does not properly compute new distroManagement.site.URL or project.URLs for projects
release:stage does not properly compute new distroManagement.site.URL or
project.URLs for projects
--
Key: MRELEASE-395
URL: http://jira.codehaus.org/browse/MRELEASE-395
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-8
Reporter: John Allen
Priority: Blocker
In the case where you have a multi-module project and each module has its own
distributionManagement.site.url which is common with projects that like their
sites to be version numbered (see example beolw) the release:stage plugin fails
to get the project's site properly deployed. From a brief look it seems
release:sxtage is only computing a new URL for the owning project and not all
the child projects. What's more it looks like its changing the site deployment
URL and not the project's corresponding project URL. This results in the site
deployment for children going to their original pom.xml specific locations
regardless of them being 'staged' (i.e. they're not staged, they've just gone
live!). Nearly as bad is that all the relative links for connecting modules and
parents and banners together are broken too, as they are based upoin the
project.URL which hasnt been touched by the release:stage mojo. site:stage
makes a better fist of this, basically you need to remap the entire URL domain
(site distro and project url) to be under some other parent space for you to
successfully stage sites (see site:stage)
This kind of mistake has come up in the past, simply put a project can define
all its own settings for everything so anything that makes assumptions based on
inheritence or 'defaults' is just gonna break the system.
Example of how sub-project's defining their own site deployemtn and project URL
information:
{noformat}
site
urldav:https://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}/url
/site
urlhttp://example.com/maven/sites/${mvn.repoName}/${project.groupId}/${project.artifactId}/${project.version}//url
{noformat}
--
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: (DOXIA-265) Add an EntityResolver in AbstractXmlParser#getXmlReader()
[ http://jira.codehaus.org/browse/DOXIA-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-265. - Assignee: Vincent Siveton Resolution: Fixed Fixed in [r723989|http://svn.apache.org/viewvc?rev=723989view=rev] Add an EntityResolver in AbstractXmlParser#getXmlReader() - Key: DOXIA-265 URL: http://jira.codehaus.org/browse/DOXIA-265 Project: Maven Doxia Issue Type: Improvement Components: Core Affects Versions: 1.0-beta-1 Reporter: Vincent Siveton Assignee: Vincent Siveton Fix For: 1.0-beta-1 -- 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-264) XhtmlBaseSink and sub classes should create a valid XHTML
[ http://jira.codehaus.org/browse/DOXIA-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated DOXIA-264: -- Fix Version/s: (was: 1.0-beta-1) 1.0-beta-2 XhtmlBaseSink and sub classes should create a valid XHTML - Key: DOXIA-264 URL: http://jira.codehaus.org/browse/DOXIA-264 Project: Maven Doxia Issue Type: Improvement Components: Module - Xhtml Affects Versions: 1.0-alpha-11 Reporter: Vincent Siveton Assignee: Vincent Siveton Fix For: 1.0-beta-2 Some tags are wrongly written and then XHTML is not valid according the DTD: * img tag should have an alt attributes * head tag should have a title tag inside * p should not be write for list and verbatim -- 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-226) Make XML based parsers better handle whitespace
[
http://jira.codehaus.org/browse/DOXIA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated DOXIA-226:
--
Fix Version/s: (was: 1.0-beta-1)
1.0-beta-2
Make XML based parsers better handle whitespace
---
Key: DOXIA-226
URL: http://jira.codehaus.org/browse/DOXIA-226
Project: Maven Doxia
Issue Type: Improvement
Reporter: Benjamin Bentmann
Fix For: 1.0-beta-2
Regarding whitespace in XML documents, one needs to consider the following
aspects:
- ignorable whitespace, i.e. view {{tr td/ /tr}} and
{{trtd//tr}} as equivalent
- collapsible whitespace, i.e. view {{Text nbsp; Text}} and {{Text
Text}} as equivalent
- trimmable whitespace, i.e. view {{p Text /p}} and {{pText/p}}
as equivalent
Those distinctions require a DTD/XSD in combination with a validating parser
and/or application-specific knowledge. For robustness, doxia parsers for
XML-based formats should not depend on the existence of a schema definition
such that they reliably deliver events into the sinks. Hence I suggest to
hard-code the required logic for proper whitespace handling into each parser.
Currently, whitespace handling is rather static, e.g. {{XhtmlBaseParser}}
pushes all input whitespace into the sink. This might cause troubles with
sinks that are not expected to receive ignorable whitespace. To address this
issue, it seems helpful if {{AbstractXmlParser}} provided a default
implementation of {{handleText()}} that subclasses can simply control via
state flags instead of implementing {{handleText()}} from scratch in each
parser. CopyPaste - which caused DOXIA-225 - needs to be avoided.
More precisely, I image the following changes:
- Have {{AbstractXmlParser}} maintain a stack of tuples (ignorable,
collapsible, trimmable) where each tuple describes the whitespace handling
for the currently parsed element
- Have {{AbstractXmlParser}} push/pop a tuple from this stack before/after
calling {{handleStartTag()}}/{{handleEndTag()}}
- Have {{AbstractXmlParser}} provide setters to allow subclasses to control
the desired whitespace handling in their {{handleStartTag()}} implementation
- Have {{AbstractXmlParser}} implement {{handleText()}} where it evalutes the
top-most tuple from the stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-2250) Upload bundle for opensymhony.org's quartz scheduler
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen updated MAVENUPLOAD-2250: - Attachment: quartz161bundle.zip Updated attachment Upload bundle for opensymhony.org's quartz scheduler Key: MAVENUPLOAD-2250 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2250 Project: Maven Upload Requests Issue Type: Wish Reporter: David J. M. Karlsen Attachments: org.opensymphony.quartz.161.zip, quartz161bundle.zip Bundle attached as file upload -- 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-3890) Transitive dependencies override explicitly set scope.
[ http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3890: --- Affects Version/s: 3.0-alpha-1 2.1.0-M1 Transitive dependencies override explicitly set scope. -- Key: MNG-3890 URL: http://jira.codehaus.org/browse/MNG-3890 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1 Reporter: Stephan Kleine Priority: Critical Attachments: testcase.tar.bz2 Transitive dependencies override explicitly set scope. E.g. a project A depends on Hibernate with default scope and a project B depends on project A as well as on Hibernate for which it sets the scope explicitly to provided. Further an EAR project C depends on project B (see the attached testcase). Now I would expect that C does not contain any jars for Hibernate and its dependencies since B explicitly set the scope to provided. Sadly this is not the case and C contains all hibernate jars. The only way around this I have found is setting the scope to provided for Hibernate in A as well - which is just a crude hack that produces other issues. IMHO this is a bug because Maven should respect the overridden dependency scope since the current way forces me to set the scope to provided in A which is just wrong. Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3890) Transitive dependencies override explicitly set scope.
[
http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157099#action_157099
]
Benjamin Bentmann commented on MNG-3890:
IT has been created from provided example with test artifacts to exhibit
problem:
{noformat}
[INFO]
[INFO] [dependency:tree]
[INFO] org.apache.maven.its.mng3890:b:jar:0.1
[INFO] \- org.apache.maven.its.mng3890:a:jar:0.1:compile
[INFO]
[INFO] [dependency:tree]
[INFO] org.apache.maven.its.mng3890:c:jar:0.1
[INFO] +- org.apache.maven.its.mng3890:a:jar:0.1:provided (scope not updated to
compile)
[INFO] \- org.apache.maven.its.mng3890:b:jar:0.1:compile
[INFO]
[INFO] [dependency:tree]
[INFO] org.apache.maven.its.mng3890:test:jar:1.0
[INFO] \- org.apache.maven.its.mng3890:c:jar:0.1:compile
[INFO]\- org.apache.maven.its.mng3890:b:jar:0.1:compile
[INFO] \- org.apache.maven.its.mng3890:a:jar:0.1:compile ERROR:
Should be excluded because declared as provided by c
[INFO]
{noformat}
Transitive dependencies override explicitly set scope.
--
Key: MNG-3890
URL: http://jira.codehaus.org/browse/MNG-3890
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
Reporter: Stephan Kleine
Priority: Critical
Attachments: testcase.tar.bz2
Transitive dependencies override explicitly set scope.
E.g. a project A depends on Hibernate with default scope and a project B
depends on project A as well as on Hibernate for which it sets the scope
explicitly to provided. Further an EAR project C depends on project B (see
the attached testcase).
Now I would expect that C does not contain any jars for Hibernate and its
dependencies since B explicitly set the scope to provided. Sadly this is
not the case and C contains all hibernate jars. The only way around this I
have found is setting the scope to provided for Hibernate in A as well -
which is just a crude hack that produces other issues.
IMHO this is a bug because Maven should respect the overridden dependency
scope since the current way forces me to set the scope to provided in A which
is just wrong.
Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm.
--
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-78) create dependency classification system to minimize local repo bloat
[ http://jira.codehaus.org/browse/MNG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-78: - Attachment: (was: wellbutrin-xl.html) create dependency classification system to minimize local repo bloat Key: MNG-78 URL: http://jira.codehaus.org/browse/MNG-78 Project: Maven 2 Issue Type: Task Environment: n/a Reporter: John Casey Attachments: xanax-online.html, xanax-valium.html Original Estimate: 8 hours Remaining Estimate: 8 hours Currently, all dependencies are resolved and retrieved transitively before a project is built. This means that any dependencies included in other projects' poms purely for testing purposes (f.e. jmock, junit, httpunit, etc.) will also be downloaded, regardless of whether the current project actually needs them for testing. The net result is a bloated local repository, as all testing, etc. [non-runtime] dependencies of each dependency project is retrieved. One facet of the consequences of this can be seen in MNG-77. There has been some talk about how best to classify dependencies within maven, but as far as I know, nothing concrete has come out of it. I would like to nail this particular functionality down, and get it implemented, to reduce the overhead of manual POM construction, among other things. Often, it is completely inappropriate to include compile-time dependencies in a bundled distro (f.e. EJBs cannot include j2ee.jar). This issue has seen some play on the maven-1 lists lately, and I'd like to hit it out of the park with m2. -- 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-78) create dependency classification system to minimize local repo bloat
[ http://jira.codehaus.org/browse/MNG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-78: - Attachment: (was: xanax-online.html) create dependency classification system to minimize local repo bloat Key: MNG-78 URL: http://jira.codehaus.org/browse/MNG-78 Project: Maven 2 Issue Type: Task Environment: n/a Reporter: John Casey Original Estimate: 8 hours Remaining Estimate: 8 hours Currently, all dependencies are resolved and retrieved transitively before a project is built. This means that any dependencies included in other projects' poms purely for testing purposes (f.e. jmock, junit, httpunit, etc.) will also be downloaded, regardless of whether the current project actually needs them for testing. The net result is a bloated local repository, as all testing, etc. [non-runtime] dependencies of each dependency project is retrieved. One facet of the consequences of this can be seen in MNG-77. There has been some talk about how best to classify dependencies within maven, but as far as I know, nothing concrete has come out of it. I would like to nail this particular functionality down, and get it implemented, to reduce the overhead of manual POM construction, among other things. Often, it is completely inappropriate to include compile-time dependencies in a bundled distro (f.e. EJBs cannot include j2ee.jar). This issue has seen some play on the maven-1 lists lately, and I'd like to hit it out of the park with m2. -- 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-78) create dependency classification system to minimize local repo bloat
[ http://jira.codehaus.org/browse/MNG-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-78: - Attachment: (was: xanax-valium.html) create dependency classification system to minimize local repo bloat Key: MNG-78 URL: http://jira.codehaus.org/browse/MNG-78 Project: Maven 2 Issue Type: Task Environment: n/a Reporter: John Casey Original Estimate: 8 hours Remaining Estimate: 8 hours Currently, all dependencies are resolved and retrieved transitively before a project is built. This means that any dependencies included in other projects' poms purely for testing purposes (f.e. jmock, junit, httpunit, etc.) will also be downloaded, regardless of whether the current project actually needs them for testing. The net result is a bloated local repository, as all testing, etc. [non-runtime] dependencies of each dependency project is retrieved. One facet of the consequences of this can be seen in MNG-77. There has been some talk about how best to classify dependencies within maven, but as far as I know, nothing concrete has come out of it. I would like to nail this particular functionality down, and get it implemented, to reduce the overhead of manual POM construction, among other things. Often, it is completely inappropriate to include compile-time dependencies in a bundled distro (f.e. EJBs cannot include j2ee.jar). This issue has seen some play on the maven-1 lists lately, and I'd like to hit it out of the park with m2. -- 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: (MCHANGELOG-90) Developer activity can't resolve developer name using clearcase SCM
Developer activity can't resolve developer name using clearcase SCM --- Key: MCHANGELOG-90 URL: http://jira.codehaus.org/browse/MCHANGELOG-90 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Rational Clearcase, Maven 2.0.9, Red Hat Linux Reporter: Peter Hayes Attachments: changelog.xml The change log changelog.xml file generated when using clearcase as an SCM provider includes an additional space after the user id. This prevents the matching of userid to pom's developer's id. I checked the scm:changelog output and it does not include a space so it seems that this is a changelog issue. I have attached a sample changelog.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-358) site.xml urls are not always correct
[
http://jira.codehaus.org/browse/MSITE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157108#action_157108
]
John Allen commented on MSITE-358:
--
Over enthusiatsic application or resolveRelativeLinks, probably in
assembleInheritance. However the same 'issue' applies to modules and parent
URLs. relatives URLs are used where ever possible so that you can stage a
collection of projects together and they will link to each other but eventually
you'll hit a parent say that you've not staged but, if you were deploying to
the real location, would be available via a relative, and that link will
therefore be invalid in your staged environment.
I presume you're refering to site:stage in this.
I note in the banners those are full URLs and not relatives. What if they were
relatives? If my parent site.xml defined that it uses .,/images/foo what should
the child have for those resource locations? Is it true that the it will be
using the same skin? it may be inherting the parent's site.xml but it could it
not be using its own skin that does not contain that specifc image? Is multiple
inheritence of skins allowed or does the child's skin override the parents? If
its the later then what resource indicator is correct for an image that only
exists in the parent?
I expect just not changing them to relatives would best.
site.xml urls are not always correct
Key: MSITE-358
URL: http://jira.codehaus.org/browse/MSITE-358
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Reporter: Brian Fox
Priority: Blocker
Fix For: 2.0-beta-8
This is so completely broken that it must be fixed before another release
occurs.
The maven-parent site.xml defines some images as:
{noformat}
bannerLeft
name${project.name}/name
srchttp://maven.apache.org/images/apache-maven-project-2.png/src
hrefhttp://maven.apache.org//href
/bannerLeft
bannerRight
srchttp://maven.apache.org/images/maven-logo-2.gif/src
/bannerRight
{noformat}
The site plugin somewhere along the line replaces these urls with ../../
repeated based on how far down the inheritence tree you are from
maven-parent. This means you can't stage or deploy a site to a different
location than the maven-parent because all urls will point back to
maven-parent's /images. Worse, every module has its own copy of the css and
images so there's no reason for it to depend on the parent at all.
--
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-163) The modules menu is not inherited if the parent project has no modules of its own
[ http://jira.codehaus.org/browse/MSITE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157109#action_157109 ] John Allen commented on MSITE-163: -- Worth seeing MSHARED-83 too. The modules menu is not inherited if the parent project has no modules of its own - Key: MSITE-163 URL: http://jira.codehaus.org/browse/MSITE-163 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-4 Environment: ubuntu linux / debian linux Reporter: Andrew Williams Fix For: 2.0-beta-8 if I have a site.xml in a parent project that contains the line menu ref=modules inherit=top / it is not inherited by child projects. menu ref=reports inherit=top / works, as does parent. This happens when the parent project has no modules of its own. -- 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-136) when inheriting site.xml the menu ref='parent' expands to a menu with links for *all* ancestors and not just the immediate parent
[ http://jira.codehaus.org/browse/MSITE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157110#action_157110 ] John Allen commented on MSITE-136: -- Patch for this is in MSHARED-83 when inheriting site.xml the menu ref='parent' expands to a menu with links for *all* ancestors and not just the immediate parent --- Key: MSITE-136 URL: http://jira.codehaus.org/browse/MSITE-136 Project: Maven 2.x Site Plugin Issue Type: Bug Components: inheritance Affects Versions: 2.0-beta-5 Environment: 2.0.4 Reporter: John Allen Fix For: 2.0-beta-8 multi-project environment; root project provides site.xml root/sub1/sub2/sub3/sub4 site pages get rendered with parent menu containing links for all the ancestors and not just the immediate sub3 parent. copying root's site.xml into sub4 results in parent being correctly rendered. did not test the results of copying site.xml into the middle of the ancestry so cant say whether the parents list starts at the project that defines the site.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157111#action_157111
]
John Allen commented on MSITE-129:
--
Modules should be modules and not children? Fixed in patch attached to
MSHARED-83
modules list empty if modules don't use this project as parent in reactor
build
---
Key: MSITE-129
URL: http://jira.codehaus.org/browse/MSITE-129
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.0-beta-5
Reporter: Kenney Westerhof
Assignee: Kenney Westerhof
Priority: Minor
Fix For: 2.0-beta-8
The code in the AbstractSiteRenderingMojo does the following:
- if it's running in a reactor build (i.e. more than 1 project in the reactor
projects) it scans all
projects to see if it's parent project equals the current project. If so,
it's marked as a module.
- if it's running on a single project, the project.build.modules is consulted
and those modules
are marked as modules.
I've got a 'fake' root pom, for utility purposes: it lists all projects as
modules so that I can easily
built everything and generate a site. However, this fake root pom is never
used as a parent - there's
a /pom/pom.xml project for that.
The result of this is that the modules list is empty.
A workaround is to first run 'mvn site' and then 'mvn site -N'.
I'm not sure what the correct solution should be - basically now 2 site
layouts are implemented:
- a physical layout where the modules match the modules section of the pom,
reflecting filesystem layout,
- a project hierarchy layout based on parent
and one or the other is used depending on wheter the build contains more than
1 project or not.
My first feeling is that since the tag is called ${modules} (or menu
ref=modules/) that
the site should use the modules, not the parent.
It should also take into consideration, that IF a reactor build is running,
it should only use the modules that are also
in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
site with not all projects in it).
Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2274) Docbook (net.sf.docbook) upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157112#action_157112 ] Cedric Pronzato commented on MAVENUPLOAD-2274: -- Hello, Concerning the repository you could use this: net.sf.docbook,[EMAIL PROTECTED]:/home/groups/d/do/docbook/htdocs/maven/repository,rsync_ssh,Cedric Pronzato,[EMAIL PROTECTED],, But I don't know if I have to setup something for the previous mavensync user in sourceforge or if it will work out of the box. I haven't find much docs about how to configure properly a maven sourceforge repository. If you have any link, let me know it. Concerning the docbook related things on org.docbook groupId, on the project no one seems to know who made this artefact. So how do you want to proceed? Regards, Cédric, Docbook (net.sf.docbook) upload --- Key: MAVENUPLOAD-2274 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2274 Project: Maven Upload Requests Issue Type: Wish Reporter: Cedric Pronzato Hello, I am developer in the docbook project and I would like to deploy the following bundles on maven central repository: - http://docbook.sourceforge.net/maven/dist/docbook-5.0-bundle.jar - http://docbook.sourceforge.net/maven/dist/docbook-xml-5.0-bundle.jar - http://docbook.sourceforge.net/maven/dist/docbook-xsl-1.74.0-bundle.jar - http://docbook.sourceforge.net/maven/dist/docbook-xsl-saxon-1.0.0-bundle.jar - http://docbook.sourceforge.net/maven/dist/docbook-xsl-xalan-1.0.0-bundle.jar Here are some other informations: - groupId: net.sf.docbook - my developer nick name is mimil and is listed in the given contributor url - The bundles have been made using the jar command because most of my artifacts are pom package type and it sounds to not be compatible with the repository:bundle-create plugin. - docbook-5.0-bundle.jar is the parent pom and then do not contains artifact Regards, Mimil -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2286) nez sync rule from sourceforge project
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157116#action_157116 ] Christophe Lallement commented on MAVENUPLOAD-2286: --- Yes you'r right but when i look at https://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csvjv i find both: some project with only root dns and other with full dns name. let's go for net.java.dev.jvyaml,[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,[EMAIL PROTECTED],, nez sync rule from sourceforge project -- Key: MAVENUPLOAD-2286 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 Project: Maven Upload Requests Issue Type: Wish Reporter: Christophe Lallement org.jvyaml,[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,ouaibsky.free.fr,, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2287) New opensource library (swing) to sync with central repository: JBusyComponent
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157117#action_157117 ] Christophe Lallement commented on MAVENUPLOAD-2287: --- yes, let's go for com.google.code.jbusycomponent ,[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,[EMAIL PROTECTED],, New opensource library (swing) to sync with central repository: JBusyComponent -- Key: MAVENUPLOAD-2287 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 Project: Maven Upload Requests Issue Type: Wish Reporter: Christophe Lallement org.divxdede,[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo,rsync_ssh,Ouaibsky,[EMAIL PROTECTED],, -- 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-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=157119#action_157119 ] Olivier Lamy commented on SCM-317: -- Hi, Can you provide a new path with the current trunk ? I can't commit your patch AS IS I have some errors when applying it. Thanks. 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.1.1 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] Created: (MAVENUPLOAD-2297) Upload bundle for saxon 9.1.0.2 b
Upload bundle for saxon 9.1.0.2 b - Key: MAVENUPLOAD-2297 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2297 Project: Maven Upload Requests Issue Type: Wish Reporter: David J. M. Karlsen Upload bundle for free / opensource version of Saxon. -- 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: (MANTTASKS-124) Setting dependencies with the provided scope does not work
Setting dependencies with the provided scope does not work -- Key: MANTTASKS-124 URL: http://jira.codehaus.org/browse/MANTTASKS-124 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.0.9 Environment: OS X 10.4.11, Java 5, Ant 1.7.0, Ant 1.6.5 Reporter: John Gibson If you use the provided scope to pull in dependences like this: artifact:dependencies pathId=osgi.provided.classpath filesetId=osgi.provided.fileset verbose=true useScope=provided pom refid=osgi.maven.project / remoteRepository refid=m2.repository/ /artifact:dependencies Then the result classpath and fileset are empty despite the POM containing definitions like this: ... dependencies dependency groupIdorg.osgi/groupId artifactIdosgi-compendium/artifactId version4.1.0/version scopeprovided/scope /dependency dependency groupIdorg.osgi/groupId artifactIdosgi-core/artifactId version4.1.0/version scopeprovided/scope /dependency ... /dependencies I would expect to have the path/fileset contain at least those two jars (I'm not sure about transitive dependencies, however). Other users have encountered this issue, see here: http://www.nabble.com/maven-ant-tasks-and-the-provided-scope-td19662878.html -- 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: (MSANDBOX-40) Maven truezip sandbox - add configuration for additional archives
[ http://jira.codehaus.org/browse/MSANDBOX-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed MSANDBOX-40. Assignee: Dan Tran Resolution: Fixed fixed at Revision: 8295 Author: dantran Date: 7:34:42 PM, Saturday, December 06, 2008 Message: recognize sar|swc|nar|esb|par|rar extensions as jar archives Modified : /trunk/sandbox/truezip-maven-plugin/pom.xml Modified : /trunk/sandbox/truezip-maven-plugin/src/main/resources/META-INF/services/de.schlichtherle.io.registry.properties Maven truezip sandbox - add configuration for additional archives - Key: MSANDBOX-40 URL: http://jira.codehaus.org/browse/MSANDBOX-40 Project: Maven 2.x Sandbox Issue Type: Improvement Reporter: Rasto Cesnek Assignee: Dan Tran Priority: Trivial Please, consider adding (extending) the configuration of the maven truezip plugin to support other usefull archive types (e.g. JBoss SAR/HAR). This would come very handy, because the truezip plugin is very usefull e.g. to modify dependent archives in resulting packagings (modifying/replacing MANIFESTs, etc). I also submitted an enhancement request to include these archive types into the configuration of the truezip project, itself. -- 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: (WAGON-248) wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory
wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory Key: WAGON-248 URL: http://jira.codehaus.org/browse/WAGON-248 Project: Maven Wagon Issue Type: Bug Components: wagon-file Affects Versions: 1.0-beta-4 Environment: windows, linux Reporter: Dan Tran When the requested resource has a / at the end, it is an indication of directory check. The fix is needed to get wagon:list working with file protocol -- 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: (WAGON-248) wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory
[ http://jira.codehaus.org/browse/WAGON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-248: --- Fix Version/s: 1.0-beta-5 wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory Key: WAGON-248 URL: http://jira.codehaus.org/browse/WAGON-248 Project: Maven Wagon Issue Type: Bug Components: wagon-file Affects Versions: 1.0-beta-4 Environment: windows, linux Reporter: Dan Tran Fix For: 1.0-beta-5 When the requested resource has a / at the end, it is an indication of directory check. The fix is needed to get wagon:list working with file protocol -- 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: (WAGON-248) wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory
[ http://jira.codehaus.org/browse/WAGON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-248: --- Testcase included: yes Patch Submitted: [Yes] wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory Key: WAGON-248 URL: http://jira.codehaus.org/browse/WAGON-248 Project: Maven Wagon Issue Type: Bug Components: wagon-file Affects Versions: 1.0-beta-4 Environment: windows, linux Reporter: Dan Tran Fix For: 1.0-beta-5 Attachments: WAGON-248.diff When the requested resource has a / at the end, it is an indication of directory check. The fix is needed to get wagon:list working with file protocol -- 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: (WAGON-248) wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory
[ http://jira.codehaus.org/browse/WAGON-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated WAGON-248: --- Attachment: WAGON-248.diff attached is the patch with test wagon-file's FileWagon.resourceExists should check for directory when resouce indicate it is a directory Key: WAGON-248 URL: http://jira.codehaus.org/browse/WAGON-248 Project: Maven Wagon Issue Type: Bug Components: wagon-file Affects Versions: 1.0-beta-4 Environment: windows, linux Reporter: Dan Tran Fix For: 1.0-beta-5 Attachments: WAGON-248.diff When the requested resource has a / at the end, it is an indication of directory check. The fix is needed to get wagon:list working with file protocol -- 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
