[ http://jira.codehaus.org/browse/MWAR-71?page=comments#action_73086 ]
Marcel May commented on MWAR-71:
The cause of the different maven-war-plugin versions is a mystery ... I would
expect mvn to use the 2.0 version configured for simple-partial-update project,
when building from the subproject and from the top since it is defined so in
the subproject POM.. Maybe check what "mvn projecthelp\:effective-pom" says for
the top and for the subproject...
Sorry, can't build the source code since some deps are missing
(javax.servlet.jsp:jsp-api), and
http://download.java.net/javaee5/external/shared repo is not accessible (from
outside of Sun I guess :-))
BTW, I recommend you use a central pluginManagement entry for plugin
versions/defaul config management, and a central dependencyManagement section.
That way, you avoid spreading dependency and plugin version configuration all
over your POMs.
Like in you master pom, which already contains the compiler plugin. Maybe this
will work for your maven-war-plugin version problem at the moment, too.
> 2.0 works, 2.0-beta-2 does not
> --
>
> Key: MWAR-71
> URL: http://jira.codehaus.org/browse/MWAR-71
> Project: Maven 2.x War Plugin
> Issue Type: Bug
> Environment: Mac OS X
>Reporter: Ed Burns
> Attachments: code.bugreport.tar.gz
>
>
> I have a multi-module build.
> This is present in the build output when I do mvn from within the submodule
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-war-plugin:2.0:war'
> -->
> [DEBUG] (s) classesDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/classes
> [DEBUG] (f) filters = []
> [DEBUG] (f) outputDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target
> [DEBUG] (f) primaryArtifact = true
> [DEBUG] (s) project = [EMAIL PROTECTED]
> [DEBUG] (f) warName = jsf-simple-partial-update
> [DEBUG] (s) warSourceDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/src/main/webapp
> [DEBUG] (s) directory = src/main/java
> [DEBUG] (s) targetPath = WEB-INF
> [DEBUG] (s) directory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/../sunbrand/src/main/webapp
> [DEBUG] (f) webResources = [Lorg.apache.maven.model.Resource;@392356
> [DEBUG] (s) webappDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/jsf-simple-partial-update
> [DEBUG] (f) workDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/war/work
> [DEBUG] -- end configuration --
> but this present when I run the build from the top level
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-war-plugin:2.0-beta-2:war' -->
> [DEBUG] (s) classesDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/classes
> [DEBUG] (f) outputDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target
> [DEBUG] (s) project = [EMAIL PROTECTED]
> [DEBUG] (f) warName = jsf-simple-partial-update
> [DEBUG] (s) warSourceDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/src/main/webapp
> [DEBUG] (s) webappDirectory =
> /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/jsf-simple-partial-update
> [DEBUG] -- end configuration --
> I would think the behaviour would be the same regardless of which
> version of the maven-war-plugin is pulled in.
--
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
XStream 1.2
---
Key: MAVENUPLOAD-1076
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1076
Project: maven-upload-requests
Issue Type: Task
Reporter: Joerg Schaible
Please sync Codehaus repo! What's the proper task for such a request? I already
tried on the dev list two days ago.
--
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
Summary / project group pages should be a tree view with relationship
--
Key: CONTINUUM-829
URL: http://jira.codehaus.org/browse/CONTINUUM-829
Project: Continuum
Issue Type: Improvement
Reporter: Kenney Westerhof
--
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
Logback 0.2.5 upload request
Key: MAVENUPLOAD-1077
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1077
Project: maven-upload-requests
Issue Type: Task
Reporter: Sebastien Pennec
Attachments: logback-access-0.2.5-bundle.jar,
logback-classic-0.2.5-bundle.jar, logback-core-0.2.5-bundle.jar
The logback project recently released version 0.2.5 of all three modules.
Please kindly add the attached files to ibiblio's maven repository.
--
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
[
http://jira.codehaus.org/browse/MAVENUPLOAD-1077?page=comments#action_73089 ]
Sebastien Pennec commented on MAVENUPLOAD-1077:
---
Easy access to urls:
http://jira.codehaus.org/secure/attachment/22427/logback-access-0.2.5-bundle.jar
http://jira.codehaus.org/secure/attachment/22426/logback-classic-0.2.5-bundle.jar
http://jira.codehaus.org/secure/attachment/22425/logback-core-0.2.5-bundle.jar
> Logback 0.2.5 upload request
>
>
> Key: MAVENUPLOAD-1077
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1077
> Project: maven-upload-requests
> Issue Type: Task
>Reporter: Sebastien Pennec
> Attachments: logback-access-0.2.5-bundle.jar,
> logback-classic-0.2.5-bundle.jar, logback-core-0.2.5-bundle.jar
>
>
> The logback project recently released version 0.2.5 of all three modules.
> Please kindly add the attached files to ibiblio's maven repository.
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-827?page=comments#action_73092
]
Mattias Andersson commented on CONTINUUM-827:
-
I see the same behaviour with CVS as SCM provider. Only a list of files changed
and no developer or commit message (this worked fine in 1.0.2). See the exampel
below. It's the same in the build result view (See attached picture).
Online report :
http://sorken-wm2:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/11/buildId/999
Build statistics:
State: Ok
Previous State: Building
Started at: fr, 2006-08-18 01:19:51 +0200
Finished at: fr, 2006-08-18 02:14:54 +0200
Total time: 55m 2s
Build Trigger: Schedule
Exit code: 0
Building machine hostname: sorken-wm2
Operating system : Windows 2003(Service Pack 1)
Java version : 1.4.2_10(Sun Microsystems Inc.)
Changes
scripts/Database/factorydata/CAT_CUSTOMER_GROUP.dat
scripts/Database/factorydata/SYS_SUBSYSTEM_ROLE_ACCESS.dat
scripts/Database/factorydata/SYS_USER_GROUPS.dat
...
> notification emails missing svn information
> ---
>
> Key: CONTINUUM-827
> URL: http://jira.codehaus.org/browse/CONTINUUM-827
> Project: Continuum
> Issue Type: Bug
> Components: SCM
>Affects Versions: 1.0.3
>Reporter: Brian Fox
> Fix For: 1.1
>
>
> I'm using 1.0.3 and svn 1.3.2. 99% of the time, the notifications do not list
> the developer or the commit message. I just get a list of changed files. I
> have seen it in the past occasionally but almost always the info isn't there.
> This includes times when there was only 1 commit since the last build.
--
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
Add classifier fonctionnality to Maven EAR Plugin
-
Key: MEAR-36
URL: http://jira.codehaus.org/browse/MEAR-36
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.2
Environment: Any
Reporter: Mathieu Rozieres
The tag is not implemented into Maven EAR Plugin.
For example, while using this configuration :
org.apache.maven.plugins
maven-ear-plugin
dev
The artefact produced is still named ${pom.artifactId}-${pom.version} ...
--
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
LegacyArtifactDiscoverer doesn"t handle "javadoc.jars" type
---
Key: MRM-152
URL: http://jira.codehaus.org/browse/MRM-152
Project: Maven Repository Manager
Issue Type: Improvement
Components: discovery
Reporter: nicolas de loof
Attachments: LegacyArtifactDiscoverer.java.patch
"javadoc.jars" type is used in maven1 repo for javadoc bundles. It is not
commonly used, but support for it has recently be added to eclipse plugin, and
it can be usefull for non-redistribuable artifacts that have private sources.
--
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
repositories section in settings.xml ignored (trunk - 0.0.10 candidate)
---
Key: MNGECLIPSE-186
URL: http://jira.codehaus.org/browse/MNGECLIPSE-186
Project: Maven 2.x Extension for Eclipse
Issue Type: Bug
Components: Repository Management
Affects Versions: 0.0.10
Environment: Eclipse 3.1/3.2 for Windows
Reporter: Marek Bieganski
Assigned To: Eugene Kuleshov
Repositories section in settings.xml ignored. It worked ok in 0.0.9
When I switched to unreleased version from trunk, i had to configure remote
repositories in every pom.
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: (was: index-improve-content-visibility.html)
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> index[new_nav_items_w_top_right_quicklinks].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: (was: index-draft-plugin-subsite.html)
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> index[new_nav_items_w_top_right_quicklinks].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: index[new_nav_items].html
MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
MNG-2473-site-[new_nav_items].patch
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> index[new_nav_items_w_top_right_quicklinks].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: index[new_nav_items_w_top_right_quicklinks].html
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> index[new_nav_items_w_top_right_quicklinks].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-830?page=all ]
John Casey updated CONTINUUM-830:
-
Summary: Use redirect after post instead of forward when page refresh is
common but could cause re-triggering (was: Always use redirect after post, not
forward)
*sigh* de-generalizing a bit
> Use redirect after post instead of forward when page refresh is common but
> could cause re-triggering
>
>
> Key: CONTINUUM-830
> URL: http://jira.codehaus.org/browse/CONTINUUM-830
> Project: Continuum
> Issue Type: Improvement
> Components: Web interface
>Affects Versions: 1.0.3
>Reporter: John Casey
> Fix For: 1.1
>
>
> When I force a build, Continuum simply forwards me to the summary page,
> instead of redirecting. This means that if I use the browser's refresh
> function, I'll force another build, since the URL is the one used to trigger
> the build. If you're doing many things at once, it means you have to look at
> the URL before you punch reload, or you may wind up rebuilding again.
> It'd be nice to simply redirect the user to the summary page, so reloads of
> the page wouldn't trigger fresh builds.
--
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
Should be able to specify all dependency qualifiers, including "classifier"
---
Key: MASSEMBLY-141
URL: http://jira.codehaus.org/browse/MASSEMBLY-141
Project: Maven 2.x Assembly Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Simon Gunzenreiner
The AssemblyIncludesArtifactFilter class currently only uses groupId and
classId to filter dependencies, but it would be very useful to be able to
filter on other dependency qualifiers as well - in particular the "classifier".
I would like to be able to filter jar files with the "sources" classifier (I
assume this is a classifier) when creating an assembly, to put those source
archive files in a different 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
When a user clicks "Force Build" or "Build All" redirect to the summary page,
instead of forwarding
---
Key: CONTINUUM-830
URL: http://jira.codehaus.org/browse/CONTINUUM-830
Project: Continuum
Issue Type: Improvement
Components: Web interface
Affects Versions: 1.0.3
Reporter: John Casey
Priority: Minor
When I force a build, Continuum simply forwards me to the summary page, instead
of redirecting. This means that if I use the browser's refresh function, I'll
force another build, since the URL is the one used to trigger the build. If
you're doing many things at once, it means you have to look at the URL before
you punch reload, or you may wind up rebuilding again.
It'd be nice to simply redirect the user to the summary page, so reloads of the
page wouldn't trigger fresh builds.
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-830?page=all ]
John Casey updated CONTINUUM-830:
-
Priority: Major (was: Minor)
Fix Version/s: 1.1
Summary: Always use redirect after post, not forward (was: When a
user clicks "Force Build" or "Build All" redirect to the summary page, instead
of forwarding)
generalizing, since this can cause all sorts of problems.
> Always use redirect after post, not forward
> ---
>
> Key: CONTINUUM-830
> URL: http://jira.codehaus.org/browse/CONTINUUM-830
> Project: Continuum
> Issue Type: Improvement
> Components: Web interface
>Affects Versions: 1.0.3
>Reporter: John Casey
> Fix For: 1.1
>
>
> When I force a build, Continuum simply forwards me to the summary page,
> instead of redirecting. This means that if I use the browser's refresh
> function, I'll force another build, since the URL is the one used to trigger
> the build. If you're doing many things at once, it means you have to look at
> the URL before you punch reload, or you may wind up rebuilding again.
> It'd be nice to simply redirect the user to the summary page, so reloads of
> the page wouldn't trigger fresh builds.
--
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
[ http://jira.codehaus.org/browse/MNGECLIPSE-186?page=all ]
Eugene Kuleshov updated MNGECLIPSE-186:
---
Affects Version/s: (was: 0.0.10)
You can't relally report issues on unreleased version.
Anyways, if you feel that something isn't right, please attach all required
configuration files and minimal test project needed to reproduce issue and also
describe exact steps how to reproduce. I don't want to guess if you have issues
with launcher or dependency resolver...
> repositories section in settings.xml ignored (trunk - 0.0.10 candidate)
> ---
>
> Key: MNGECLIPSE-186
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-186
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
> Components: Repository Management
> Environment: Eclipse 3.1/3.2 for Windows
>Reporter: Marek Bieganski
> Assigned To: Eugene Kuleshov
>
> Repositories section in settings.xml ignored. It worked ok in 0.0.9
> When I switched to unreleased version from trunk, i had to configure remote
> repositories in every pom.
--
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
Hi all
I'd like to know if this issue has been submitted:
http://jira.codehaus.org/browse/MASSEMBLY-120
IMHO, it seems it hasn't been.
I checkout the source code recently, but this feature seems to be missing.
Thanks for your help.
Alexis
[ http://jira.codehaus.org/browse/MECLIPSE-76?page=comments#action_73108 ]
mark struberg commented on MECLIPSE-76:
---
if it's only a debugging issue, you may try to use a maven-dependency-plugin
with the goal dependency:unpack.
You additionally have to use the 'Add Class Folder' in the Java Build Path
dialog and set it to the unpacked ear/war paths manually.
But you're right, we have different use-cases. My issue is to be able to
compile a war which is dependent on a derived war.
> Projects containing war's as dependency will not include war-reference
> --
>
> Key: MECLIPSE-76
> URL: http://jira.codehaus.org/browse/MECLIPSE-76
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Reporter: Tom Spengler
>
> if you have a dependency like
>
> j-core
> j-core-webapp-axx
> 0.0.1
> war
>
> it will not included int .classpath
> Resolution could be
> EclipseClasspathWriter
> --old--
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath() )
> --new --
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath()
> ||artifact.getArtifactHandler().isIncludesDependencies() )
>
> and
> EclipsePlugin.prepareArtifacts()
> --old--
> Collection artifacts = project.getTestArtifacts();
> --new--
> Collection artifacts = project.getTestArtifacts();
> Set artifact_2 = project.getArtifacts();
> for (Iterator at = artifact_2.iterator(); at.hasNext();){
> Artifact arti = (Artifact) at.next();
> if (! artifacts.contains(arti))
> artifacts.add(arti);
> }
--
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
[ http://jira.codehaus.org/browse/MECLIPSE-76?page=comments#action_73109 ]
Tom Spengler commented on MECLIPSE-76:
--
yes it's "only" for debugging.
I can't tell 100 developers you have to add all src-jars manualy, two times a
day each day.
> Projects containing war's as dependency will not include war-reference
> --
>
> Key: MECLIPSE-76
> URL: http://jira.codehaus.org/browse/MECLIPSE-76
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Reporter: Tom Spengler
>
> if you have a dependency like
>
> j-core
> j-core-webapp-axx
> 0.0.1
> war
>
> it will not included int .classpath
> Resolution could be
> EclipseClasspathWriter
> --old--
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath() )
> --new --
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath()
> ||artifact.getArtifactHandler().isIncludesDependencies() )
>
> and
> EclipsePlugin.prepareArtifacts()
> --old--
> Collection artifacts = project.getTestArtifacts();
> --new--
> Collection artifacts = project.getTestArtifacts();
> Set artifact_2 = project.getArtifacts();
> for (Iterator at = artifact_2.iterator(); at.hasNext();){
> Artifact arti = (Artifact) at.next();
> if (! artifacts.contains(arti))
> artifacts.add(arti);
> }
--
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
[ http://jira.codehaus.org/browse/MASSEMBLY-120?page=comments#action_73110
]
Alexis Midon commented on MASSEMBLY-120:
Hi, is the fix submitted?
> ModuleSet/Binaries include/exclude not implemented
> --
>
> Key: MASSEMBLY-120
> URL: http://jira.codehaus.org/browse/MASSEMBLY-120
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: linux (fedora core 5) / maven 2.0.4 / java 1.5
>Reporter: Simon Goodall
> Assigned To: John Casey
>
> The binaries section of moduleSet has an include / exclude section defined,
> but it is not implemented. Currently a module can only include all or none of
> its dependencies (through the includeDependencies tag). There is no selective
> inclusion/exclusion of dependencies.
--
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
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_73111 ]
John Casey commented on MASSEMBLY-99:
-
Are you aware that you have set to false in the
moduleSet? DependencySets are meant for direct dependencies, not dependencies
of modules.
> dependencySets in a descriptor doesn't work anymore
> ---
>
> Key: MASSEMBLY-99
> URL: http://jira.codehaus.org/browse/MASSEMBLY-99
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: all
>Reporter: Olivier Lamy
> Assigned To: John Casey
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: assembly-spike-1.0.zip, descriptor.xml
>
>
> I attached my descriptor file.
>
>
> lib
> false
> runtime
>
>
>
> unzip -l on the assembly file show empty lib directory.
> Olivier
--
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
[ http://jira.codehaus.org/browse/MWAR-60?page=comments#action_73112 ]
Fabrice BELLINGARD commented on MWAR-60:
Mike, I think Chuck is right. There should be 2 parameters:
* one that filters files when they are copied from the source project (i.e.
${basedir}) to the exploded project (i.e.
${project.build.directory}/${project.build.finalName})
** this is useful, for instance, if you want to exclude JARs stored in the SCM
under WEB-INF/lib
** IMHO, this one should be the *warSourceExcludes* (as it used to work for
version 2.0)
* one that filters files when they are packaged from the exploded project to
the WAR archive
** this is useful when you want to do your skinny WAR
** this one could be called *warExcludes*, as Chuck said
Considering this, the patch applied for
-[MWAR-39|http://jira.codehaus.org/browse/MWAR-39]- is not correct because it
uses the same parameter to do both filtering.
What's more, what is confusing is that "warSourceIncludes" has an alias, so
people don't know that they are actually modifying the same parameter :
{code:title=AbstractWarMojo.java|borderStyle=solid}
...
/**
* The comma separated list of tokens to exclude from the WAR.
*
* @parameter alias="excludes"
*/
private String warSourceExcludes;
...
{code}
We have to work on that.
> Source Excludes are being applied to WAR file
> -
>
> Key: MWAR-60
> URL: http://jira.codehaus.org/browse/MWAR-60
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: WinXP, jdk1.5.0_07, mvn 2.0.4
>Reporter: Chuck Deal
> Fix For: 2.0.2
>
>
> My scenario:
> I use Eclipse 3.1.1 to develop the web app. I run Tomcat 5.5.17 with it's
> docbase pointed at the source tree (/src/main/webapp). As a result, I have
> files that are required by Tomcat to run, but not to be included in the WAR.
> Specifically, I have a WEB-INF folder with a classes directory that includes
> classes that will actually be included in the WAR as a JAR (as well as a few
> other things).
> As you can see in the following plugin snippet, I specifically exclude the
> WEB-INF folder from the source tree because all of its contents will be
> gathered by the various stages of the build process (process-resources, etc)
> and included in the WAR when it is "exploded"
> I had been using the following plugin snippet for generating my War (war
> plugin 2.0)
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.0
>
> target/jspweb.xml
> aims
> **/*.jsp*, **/JasperReports/*.*, **/WEB-INF/**/*.*
>
>
> If you change the version from 2.0 to 2.0.1, you will no longer generate the
> same WAR file! Instead, v2.0.1 uses the source excludes and applies them to
> the WAR construction as well. This means that the exploded WEB-INF (the
> correct one) is also removed from the WAR file.
> I don't think that the source excludes should be applied to the WAR
> construction, only to the stage where the source files are "exploded" (as in
> v2.0)
--
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
Continuum Release white site pages
--
Key: CONTINUUM-831
URL: http://jira.codehaus.org/browse/CONTINUUM-831
Project: Continuum
Issue Type: Improvement
Components: Documentation
Affects Versions: 1.1
Reporter: Edwin Punzalan
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-831?page=all ]
Edwin Punzalan updated CONTINUUM-831:
-
Attachment: CONTINUUM-831-continuum-uml.patch
Attaching patch for the proposed continuum pages
> Continuum Release white site pages
> --
>
> Key: CONTINUUM-831
> URL: http://jira.codehaus.org/browse/CONTINUUM-831
> Project: Continuum
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.1
>Reporter: Edwin Punzalan
> Attachments: CONTINUUM-831-continuum-uml.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
[ http://jira.codehaus.org/browse/CONTINUUM-831?page=comments#action_73114
]
Edwin Punzalan commented on CONTINUUM-831:
--
White site deployed at
http://people.apache.org/~epunzalan/continuum-white-site/index.html
> Continuum Release white site pages
> --
>
> Key: CONTINUUM-831
> URL: http://jira.codehaus.org/browse/CONTINUUM-831
> Project: Continuum
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.1
>Reporter: Edwin Punzalan
> Attachments: CONTINUUM-831-continuum-uml.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
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_73115 ]
Olivier Lamy commented on MASSEMBLY-99:
---
in the attachment called descriptor.xml ?
> dependencySets in a descriptor doesn't work anymore
> ---
>
> Key: MASSEMBLY-99
> URL: http://jira.codehaus.org/browse/MASSEMBLY-99
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: all
>Reporter: Olivier Lamy
> Assigned To: John Casey
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: assembly-spike-1.0.zip, descriptor.xml
>
>
> I attached my descriptor file.
>
>
> lib
> false
> runtime
>
>
>
> unzip -l on the assembly file show empty lib directory.
> Olivier
--
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
[ http://jira.codehaus.org/browse/MPTEST-66?page=comments#action_73116 ]
Shinobu Kawai commented on MPTEST-66:
-
Not clear how the whole prereqs stuff work, but I was wondering if adding an
attribute to call attainGoal with the same werkz session would work.
Something like .
> 1.8 version introduces bug in other plugins
> ---
>
> Key: MPTEST-66
> URL: http://jira.codehaus.org/browse/MPTEST-66
> Project: maven-test-plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: nicolas de loof
> Assigned To: Lukas Theussl
> Fix For: 1.8.1
>
> Attachments: MPTEST-66.patch
>
>
> When maven-war-plugin is run with maven.test.skip=true, the sources are not
> compiled.
> Latest version of test-plugin has removed prereqs on java:compile &
> java:jar-resources.
> Assuming other plugins themself run the java:compile goal may have impact on
> lots of plugin and can break many application builds. I think the "test:test"
> goal may have a prereqs="java:compile,java:jar-resources", and the
> "test:compile" goal only prereqs="test:prepare-filesystem,test:test-resources"
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-309?page=comments#action_73117
]
Jesse McConnell commented on CONTINUUM-309:
---
I have this mostly merged to trunk right now but it is failing when trying to
find the surefire tests, I'll have to take a look a little later to fix
this...just wanted to update where I was on applying this
> add junit results report to website, failures to email
> --
>
> Key: CONTINUUM-309
> URL: http://jira.codehaus.org/browse/CONTINUUM-309
> Project: Continuum
> Issue Type: New Feature
>Reporter: Brett Porter
> Assigned To: Edwin Punzalan
> Fix For: 1.1
>
> Attachments: CONTINUUM-309-continuum-webapp.patch,
> CONTINUUM-309-sample.GIF, continuum-api.diff, continuum-core.diff,
> continuum-model.diff, continuum-web.diff
>
>
--
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
[ http://jira.codehaus.org/browse/MNGECLIPSE-146?page=all ]
Eugene Kuleshov updated MNGECLIPSE-146:
---
Comment: was deleted
> Less aggressive source attatchment resolution
> -
>
> Key: MNGECLIPSE-146
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-146
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Improvement
> Components: Dependency Resolver
>Affects Versions: 0.0.9
>Reporter: Adam Lewis
>Priority: Minor
>
> It would be nice if the plugin was less aggresive when trying to resolve
> source artifacts. Typically if an artifact doesn't have a source jar in the
> repo at one instant it will still not have one a few minutes later. It would
> be nice if there were a configurable retry delay so that my IDE would only go
> out once a day to look for source attatchments that had previously failed to
> be found.
--
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
[ http://jira.codehaus.org/browse/MNGECLIPSE-146?page=comments#action_73118
]
Eugene Kuleshov commented on MNGECLIPSE-146:
I comitted a stub for DownloadSourcesAction that could be contributed to the
jar entries in maven classpath container. Don't have time right now to complete
implementation, so if anyone want to submit a patch we'll be glad to accept it.
Thanks.
> Less aggressive source attatchment resolution
> -
>
> Key: MNGECLIPSE-146
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-146
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Improvement
> Components: Dependency Resolver
>Affects Versions: 0.0.9
>Reporter: Adam Lewis
>Priority: Minor
>
> It would be nice if the plugin was less aggresive when trying to resolve
> source artifacts. Typically if an artifact doesn't have a source jar in the
> repo at one instant it will still not have one a few minutes later. It would
> be nice if there were a configurable retry delay so that my IDE would only go
> out once a day to look for source attatchments that had previously failed to
> be found.
--
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
[ http://jira.codehaus.org/browse/MNG-1884?page=all ]
Milos Kleint closed MNG-1884.
-
Resolution: Fixed
fixed now.
the wagonmanager instance used by the embedder needs to be injected information
from the settings object.
> settings.xml in home directory/.m2/ doesn't have an effect
> --
>
> Key: MNG-1884
> URL: http://jira.codehaus.org/browse/MNG-1884
> Project: Maven 2
> Issue Type: Bug
> Components: Embedding
> Environment: Windows XP + J2SE 1.5 + Eclipse 3.1.0
>Reporter: Simon Vos
> Assigned To: Milos Kleint
> Fix For: 2.1
>
>
> I have to use a proxy-server to connect to the internet and for that I use a
> settings.xml file for maven2 which is configured to use the proxy server and
> a local remote server. This remote server is a server in our network which
> contains our jars, ejbs, etc. and most of the packages we use to develop our
> applications. This all works fine, but the plugin doesn't seem to keep the
> settings.xml file into account when trying to retrieve the dependencies.
> What I tried was just putting the settings.xml file I use in my home
> directory/.m2/, but the plugin doesn't react to that, eventhough it says it's
> looking there when I choose to see the debug output..
--
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
twiki parser, and sinks fixes
-
Key: DOXIA-73
URL: http://jira.codehaus.org/browse/DOXIA-73
Project: doxia
Issue Type: Improvement
Components: Core, Module - Twiki
Affects Versions: 1.0-alpha-8
Reporter: Juan F. Codagnone
Attachments: juanpatches.diff, juanpatches.tar.gz
Hi,
I have some random fixes for the twiki parser (table related) and for the
rest of the Sinks.
juanpatches.diff is the whole diff, and the juanpatches.tar.gz has the
incrementals patches with a comment.
Regards,
Juan.
r2 | juan | 2006-08-20 22:16:12 -0300 (Sun, 20 Aug 2006) | 4 lines
Changed paths:
M
/branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/latex/LatexSink.java
document start should be the first thing in a \latex file.
(if not it triggers ! LaTeX Error: \usepackage before \documentclass.)
r3 | juan | 2006-08-20 22:18:55 -0300 (Sun, 20 Aug 2006) | 5 lines
Changed paths:
M
/branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/SectionBlock.java
twiki parser generated sectionTitle events in all the sections.
The only Sink that supports that behavior is xdoc.
Now it generates sectionTitle1, sectionTitle2, ...
r6 | juan | 2006-08-21 00:49:33 -0300 (Mon, 21 Aug 2006) | 1 line
Changed paths:
M
/branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/TableBlock.java
Sink#tableRows must be called after Sink#table and before Sink#tableRow
r7 | juan | 2006-08-21 00:50:02 -0300 (Mon, 21 Aug 2006) | 1 line
Changed paths:
M
/branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/validation/AdvicedSink.java
dupe
r8 | juan | 2006-08-21 01:03:09 -0300 (Mon, 21 Aug 2006) | 1 line
Changed paths:
M
/branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/latex/LatexSink.java
implement tableCell and tableCell_
r9 | juan | 2006-08-21 01:15:30 -0300 (Mon, 21 Aug 2006) | 1 line
Changed paths:
M
/branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/rtf/RtfSink.java
implement tableHeaderCell and tableHeaderCell_ to avoid NPE
r10 | juan | 2006-08-21 01:33:30 -0300 (Mon, 21 Aug 2006) | 1 line
Changed paths:
M
/branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/TableBlock.java
something was wrong in rev6.
r11 | juan | 2006-08-21 01:41:12 -0300 (Mon, 21 Aug 2006) | 1 line
Changed paths:
M
/branches/433103/doxia-modules/doxia-module-confluence/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableBlock.java
port revisions 6 and 10 to confluence.
--
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
[ http://jira.codehaus.org/browse/DOXIA-73?page=all ]
Juan F. Codagnone updated DOXIA-73:
---
Attachment: juanpatches.tar.gz
> twiki parser, and sinks fixes
> -
>
> Key: DOXIA-73
> URL: http://jira.codehaus.org/browse/DOXIA-73
> Project: doxia
> Issue Type: Improvement
> Components: Core, Module - Twiki
>Affects Versions: 1.0-alpha-8
>Reporter: Juan F. Codagnone
> Attachments: juanpatches.diff, juanpatches.tar.gz
>
>
> Hi,
> I have some random fixes for the twiki parser (table related) and for the
> rest of the Sinks.
> juanpatches.diff is the whole diff, and the juanpatches.tar.gz has the
> incrementals patches with a comment.
> Regards,
>Juan.
>
> r2 | juan | 2006-08-20 22:16:12 -0300 (Sun, 20 Aug 2006) | 4 lines
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/latex/LatexSink.java
> document start should be the first thing in a \latex file.
> (if not it triggers ! LaTeX Error: \usepackage before \documentclass.)
>
> r3 | juan | 2006-08-20 22:18:55 -0300 (Sun, 20 Aug 2006) | 5 lines
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/SectionBlock.java
> twiki parser generated sectionTitle events in all the sections.
> The only Sink that supports that behavior is xdoc.
> Now it generates sectionTitle1, sectionTitle2, ...
>
> r6 | juan | 2006-08-21 00:49:33 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/TableBlock.java
> Sink#tableRows must be called after Sink#table and before Sink#tableRow
>
> r7 | juan | 2006-08-21 00:50:02 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/validation/AdvicedSink.java
> dupe
>
> r8 | juan | 2006-08-21 01:03:09 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/latex/LatexSink.java
> implement tableCell and tableCell_
>
> r9 | juan | 2006-08-21 01:15:30 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/rtf/RtfSink.java
> implement tableHeaderCell and tableHeaderCell_ to avoid NPE
>
> r10 | juan | 2006-08-21 01:33:30 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/TableBlock.java
> something was wrong in rev6.
>
> r11 | juan | 2006-08-21 01:41:12 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-confluence/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableBlock.java
> port revisions 6 and 10 to confluence.
>
--
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
[ http://jira.codehaus.org/browse/MEAR-36?page=all ]
Stephane Nicoll updated MEAR-36:
Fix Version/s: 2.3
> Add classifier fonctionnality to Maven EAR Plugin
> -
>
> Key: MEAR-36
> URL: http://jira.codehaus.org/browse/MEAR-36
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
> Environment: Any
>Reporter: Mathieu Rozieres
> Assigned To: Stephane Nicoll
> Fix For: 2.3
>
>
> The tag is not implemented into Maven EAR Plugin.
> For example, while using this configuration :
>
>org.apache.maven.plugins
>maven-ear-plugin
>
> dev
>
>
> The artefact produced is still named ${pom.artifactId}-${pom.version} ...
--
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
CSharp Plugins-Version overriding and transitive dependencies
-
Key: MNG-2527
URL: http://jira.codehaus.org/browse/MNG-2527
Project: Maven 2
Issue Type: Bug
Components: Multiple Language Support, Sandbox
Environment: Windows XP
Reporter: James Carpenter
Further experience with the maven csharp plugins has revealed an interesting
side affect of the current way in which maven built csharp libraries are used.
As mentioned in MNG-2369, the csharp libraries built by maven have the version
number in their name.
Assume the following library heiarchy: A depends upon B which depends upon C
(A->B->C).
Lets assume the initial versioned dependencies are as follows:
A_1.0 (explict dependency upon B_1.0)
B_1.0 (explict dependency upon C_1.0)
C_1.0
Now lets assume C has changed to add some new feature needed by a new version
of A. Lets assume that although A needs the new feature of C, the interfaces
from C used B have not changed and hence no code changes are necessary to B.
So we now try (Will not work with CSharp even though Java code would be fine):
A_2.0 (explict dependency upon B_1.0, and C_2.0) Note: 2.0 version of C
superceeds 1.0 in typical mvn fashion
B_1.0 (explict dependency upon C_1.0)
C_2.0
This new configuration fails when the unit tests for A_2.0 are run. When the
unit tests in A_2.0 are run we see that B_1.0 is looking for C_1.0 which
doesn't exist as C_2.0 has taken its place in the dependency list. Remember
that B_1.0 is looking for C_1.0 because the assembly meta-data in B_1.0 says it
needs an assembly named C_1.0.dll.
If none of the assemblies are strongly-named (assembly meta-data contains
digital signatures for each dependency) it would be sufficient if the
dependencies within the assembly meta-data didn't contain the version numbers.
(Such a change would have synergies with whatever was done for 3rd party
libraries.)
Alternatively, I think one can probably include all versions mentioned by any
of the dependencies. In this case it is important to maintain version numbers
as part of the dependency names as doing so allows them to co-exist in the same
directory. (Could be problematic for 3rd party dlls without version numbers in
their name.)
All of the above solutions require a change to the csharp maven support in some
fashion. The only solution available today is to create a new release of B
which uses the newer version of C.
A_2.0 (explict dependency upon B_2.0)
B_2.0 (explict dependency upon C_2.0)
C_2.0
The inability to override versions is both an advantage and disadvantage. As
you can see there the advantage to the current solution is that B is now known
to work with C_2.0. The disadvantage is one must re-release B just to get the
updated C version.
Summary: Version overriding with CSharp dependencies doesn't work out. A
general solution to the problem is either impossible or at least awkward. The
issue stems from the decision by MS to support digitally signed libraries, and
the particulars of the current mvn csharp plugin behavior.
--
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
Taskdef/Typedef and Plugin dependencies
---
Key: MANTRUN-59
URL: http://jira.codehaus.org/browse/MANTRUN-59
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: ttest
I'm trying to run an ant task during a Maven run. The classes for that Ant task
are included in my Maven runtime dependencies(maven.runtime.classpath).
Here the relevant snippet from my POM:
This works if I don't provide depedencies in the POM for my plugin. But if I do
provide depedencies it doesn't work. I consider this to be a bug since that
should have no effect on the behaviour of "maven.runtime.classpath". My first
guess is that this is a classloading issue. Probably by providing dependencies
the classloaders get messed up and that causes the taskdef to not load the
classes from maven.runtime.classpath because echoing the value of
maven.runtime.classpath still gives the right classpath.
I have tried all variants of dereferencing maven.runtime.classpath. Didn't work.
Also which is very interesting if I hardcode the classpath in the taskdef to
absolute pathnames it also 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
[ http://jira.codehaus.org/browse/MNG-2475?page=all ]
Vincent Siveton closed MNG-2475.
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.0.5
Not related to MSITE-156
Fixed a bug in FmlParser ie if the following exists in the answer:
{code:xml}
...1.5 ..
{code}
We need to upgrade maven-site-plugin to 2.0-SNAPSHOT or more in the site
project to handle the change
> Need to finish escaping html in
> http://maven.apache.org/general.html#Compiling-J2SE-5
> -
>
> Key: MNG-2475
> URL: http://jira.codehaus.org/browse/MNG-2475
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Faqs
>Reporter: Rick Reumann
> Assigned To: Vincent Siveton
>Priority: Minor
> Fix For: 2.0.5
>
>
> The following html needs the following < tags escaped starting at ...
> 1.5
>
>
>
> FULL SECTION:
>
> ...
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
--
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
subethasmtp 1.0.3 bundles
-
Key: MAVENUPLOAD-1078
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078
Project: maven-upload-requests
Issue Type: Task
Reporter: fabrizio giustina
subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc
plus an additional artifact for the jdk14 compatible version with a "java14"
classifier
http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar
http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar
subethasmtp-parent: only contains the parent pom
http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-bundle.jar
--
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
Remove DB settings duplication in configuration file
Key: CONTINUUM-832
URL: http://jira.codehaus.org/browse/CONTINUUM-832
Project: Continuum
Issue Type: Sub-task
Reporter: Carlos Sanchez
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-832?page=all ]
Carlos Sanchez updated CONTINUUM-832:
-
Description: The configuration file application.xml uses the db settings
in three places now, this needs to be refactored somehow.
Fix Version/s: 1.1
Component/s: Web interface
> Remove DB settings duplication in configuration file
>
>
> Key: CONTINUUM-832
> URL: http://jira.codehaus.org/browse/CONTINUUM-832
> Project: Continuum
> Issue Type: Sub-task
> Components: Web interface
>Reporter: Carlos Sanchez
> Fix For: 1.1
>
>
> The configuration file application.xml uses the db settings in three places
> now, this needs to be refactored somehow.
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-832?page=all ]
Carlos Sanchez updated CONTINUUM-832:
-
Environment: acegi branch
> Remove DB settings duplication in configuration file
>
>
> Key: CONTINUUM-832
> URL: http://jira.codehaus.org/browse/CONTINUUM-832
> Project: Continuum
> Issue Type: Sub-task
> Components: Web interface
> Environment: acegi branch
>Reporter: Carlos Sanchez
> Fix For: 1.1
>
>
> The configuration file application.xml uses the db settings in three places
> now, this needs to be refactored somehow.
--
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
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=all ]
John Casey closed MASSEMBLY-99.
---
Resolution: Fixed
You should be able to redirect module-dependencies using a moduleSet with its
own outputDirectory, and containing within it a set of DependencySets with
their own outputDirectory specifications.
See src/it/dependency-sets/massembly-99 for an example of this.
BTW, if you use true then the
outputDirectory and so forth is still inherited from the moduleSet.
> dependencySets in a descriptor doesn't work anymore
> ---
>
> Key: MASSEMBLY-99
> URL: http://jira.codehaus.org/browse/MASSEMBLY-99
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: all
>Reporter: Olivier Lamy
> Assigned To: John Casey
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: assembly-spike-1.0.zip, descriptor.xml
>
>
> I attached my descriptor file.
>
>
> lib
> false
> runtime
>
>
>
> unzip -l on the assembly file show empty lib directory.
> Olivier
--
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
[ http://jira.codehaus.org/browse/DOXIA-73?page=comments#action_73136 ]
Juan F. Codagnone commented on DOXIA-73:
You can run into these problems converting the file
http://svn.apache.org/repos/asf/maven/doxia/trunk/doxia-modules/doxia-module-twiki/src/main/resources/TWikiParserTest.twiki
to the latex, rtf, ... sinks.
> twiki parser, and sinks fixes
> -
>
> Key: DOXIA-73
> URL: http://jira.codehaus.org/browse/DOXIA-73
> Project: doxia
> Issue Type: Improvement
> Components: Core, Module - Twiki
>Affects Versions: 1.0-alpha-8
>Reporter: Juan F. Codagnone
> Attachments: juanpatches.diff, juanpatches.tar.gz
>
>
> Hi,
> I have some random fixes for the twiki parser (table related) and for the
> rest of the Sinks.
> juanpatches.diff is the whole diff, and the juanpatches.tar.gz has the
> incrementals patches with a comment.
> Regards,
>Juan.
>
> r2 | juan | 2006-08-20 22:16:12 -0300 (Sun, 20 Aug 2006) | 4 lines
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/latex/LatexSink.java
> document start should be the first thing in a \latex file.
> (if not it triggers ! LaTeX Error: \usepackage before \documentclass.)
>
> r3 | juan | 2006-08-20 22:18:55 -0300 (Sun, 20 Aug 2006) | 5 lines
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/SectionBlock.java
> twiki parser generated sectionTitle events in all the sections.
> The only Sink that supports that behavior is xdoc.
> Now it generates sectionTitle1, sectionTitle2, ...
>
> r6 | juan | 2006-08-21 00:49:33 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/TableBlock.java
> Sink#tableRows must be called after Sink#table and before Sink#tableRow
>
> r7 | juan | 2006-08-21 00:50:02 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/validation/AdvicedSink.java
> dupe
>
> r8 | juan | 2006-08-21 01:03:09 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/latex/LatexSink.java
> implement tableCell and tableCell_
>
> r9 | juan | 2006-08-21 01:15:30 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-core/src/main/java/org/apache/maven/doxia/module/rtf/RtfSink.java
> implement tableHeaderCell and tableHeaderCell_ to avoid NPE
>
> r10 | juan | 2006-08-21 01:33:30 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-twiki/src/main/java/org/apache/maven/doxia/module/twiki/parser/TableBlock.java
> something was wrong in rev6.
>
> r11 | juan | 2006-08-21 01:41:12 -0300 (Mon, 21 Aug 2006) | 1 line
> Changed paths:
>
> M
> /branches/433103/doxia-modules/doxia-module-confluence/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableBlock.java
> port revisions 6 and 10 to confluence.
>
--
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
[ http://jira.codehaus.org/browse/MNG-1542?page=comments#action_73138 ]
Jeff Maxwell commented on MNG-1542:
---
Actually my fix had a bug.
filter may be passed as NULL leading to a NPE
Here is the fixed code:
if ((filter != null) && (filter.include(artifact))|| node.filterTrail(filter))
This allows me to create filesets of all one type.
> type attribute of artifact:dependencies doesn't work for indirect dependencies
> --
>
> Key: MNG-1542
> URL: http://jira.codehaus.org/browse/MNG-1542
> Project: Maven 2
> Issue Type: Sub-task
> Components: Ant tasks
>Affects Versions: 2.0
>Reporter: Tomislav Bodor
> Fix For: 2.1
>
> Attachments: build.xml, pom.xml
>
>
> It appears that the type filter doesn't work properly with indirect
> dependencies. It doesn't look like an issue with the TypeArtifactFilter
> itself, but somewhere deeper. However, it's related to this feature, so here
> it is...
> The problem manifests with transitive dependencies that are of different
> type, e.g. a war artefact depends on a jar library. Whatever the type in that
> case (jar or war), the dependency list returned by artifact:dependencies is
> empty.
> I've traced through it and here is some more information:
> DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail.
> This iterates over the (dependency) node trail and applies the specified
> filter to each dependency in turn. If all dependencies are of the same type
> and the type matches the one specified in the filter, no problems. However,
> I've got a dependency that is a war archive and that in turn has some jar
> dependencies. If type is set to jar, filter fails when testing the first
> dependency in the trail - the war in this case and never gets to the jar. The
> result is that whatever the value of the type attribute, the dependency list
> always ends up empty for trails that contain dependencies of different types.
--
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
Clear maven markers when Maven nature is disabled
-
Key: MNGECLIPSE-187
URL: http://jira.codehaus.org/browse/MNGECLIPSE-187
Project: Maven 2.x Extension for Eclipse
Issue Type: Bug
Components: Dependency Resolver
Affects Versions: 0.0.9
Reporter: Eugene Kuleshov
Assigned To: Eugene Kuleshov
--
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
[ http://jira.codehaus.org/browse/MAVEN-1659?page=comments#action_73141 ]
Lukas Theussl commented on MAVEN-1659:
--
Tracked this down to WAGONHTTP-5, maybe we can get an alpha-7 release of
wagon-http for m11?
> Dependency jars are not downloading from remote repository placed in
> Subversion with http access
>
>
> Key: MAVEN-1659
> URL: http://jira.codehaus.org/browse/MAVEN-1659
> Project: Maven
> Issue Type: Bug
>Affects Versions: 1.1-beta-1
> Environment: Server: Apache 1.3.x with Subversion 1.1.1
> Client: Linux 2.6/Windows 2000, J2SE 5.0
>Reporter: Roman Krutyakov
> Fix For: 1.1-rc1
>
> Attachments: maven.log
>
>
> Dependencies are not downloading from remote repository if it's placed in
> Subversion with http access (with apache and mod_davsvn)
> In verbose mode maven logs (under linux):
> ---
> Getting failed dependencies: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL
> PROTECTED]
> Attempting to download slamd_client-1.8.1.jar.
> http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_client-1.8.1.jar
> - Status code: 200
> Local file is newer: not downloaded
> Attempting to download slamd_server-1.8.1.jar.
> http://server.net:81/svn/v2/trunk/target/maven//slamd/jars/slamd_server-1.8.1.jar
> - Status code: 200
> Local file is newer: not downloaded
>
> Artifact '/opt/maven-repository/slamd/jars/slamd_client-1.8.1.jar' not found
> to add to classpath
> Artifact '/opt/maven-repository/slamd/jars/slamd_server-1.8.1.jar' not found
> to add to classpath
> ---
> in local repository appropriate paths are created, but jar files are missing
> this was checked against repository server with basic auth and without
> authentication - result is the same
> affected version 1.1-beta-1, 1.0.x works well
--
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
[ http://jira.codehaus.org/browse/WAGONHTTP-5?page=all ]
Lukas Theussl updated WAGONHTTP-5:
--
Fix Version/s: 1.0-alpha-7
This is a trivial fix and it's causing us MAVEN-1659.
> The getIfNewer method fails to work if file doesn't exist locally and the
> Last-Modified header isn't sent by the server
> ---
>
> Key: WAGONHTTP-5
> URL: http://jira.codehaus.org/browse/WAGONHTTP-5
> Project: wagon-http
> Issue Type: Bug
>Affects Versions: 1.0-alpha-3
>Reporter: Kohsuke Kawaguchi
> Fix For: 1.0-alpha-7
>
>
> The code doesn't work correctly if the following two conditions are met
> simultaneously:
> (i) the local file doesn't exist --- hence the timestamp parameter is 0
> (ii) the remote server doesn't send the "Last-Modified" header.
> Since the lastModified variable is initialized to 0 in line 355, if the above
> two conditions are met,
> the following if statement at line 371 evaluates to false:
> *if ( timestamp < lastModified )
> {
> retValue = true;
> and therefore the file won't be downloaded, causing the dependency to fail.
> This used to work with Maven 1.0.2.
> To fix this problem, initialize the lastModified variable to 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
serp
Key: MAVENUPLOAD-1079
URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1079
Project: maven-upload-requests
Issue Type: Task
Reporter: Marc Prud'hommeaux
Serp is a popular open source framework for manipulating Java bytecode.
--
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
Include jspc:compile to verify all continuum-webapp jsps.
-
Key: CONTINUUM-833
URL: http://jira.codehaus.org/browse/CONTINUUM-833
Project: Continuum
Issue Type: Improvement
Reporter: Joakim Erdfelt
Attachments: CONTINUUM-jsp-precompile.patch
Include the jspc:compile step to verify all of the jsps in the continuum-webapp.
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ]
Joakim Erdfelt updated CONTINUUM-800:
-
Attachment: CONTINUUM-800-maven-user-webapp-update-2.patch
Attached CONTINUUM-800-maven-user-webapp-update-2.patch which fixes many
compile and testing issues with maven-user-webapp.
Not perfect tho. as xwork<->plexus integration seems to not be working.
The EditUserAction does not get its UserManager set via plexus.
Just uploading this so others can work off it.
> Use maven-user project for user management
> --
>
> Key: CONTINUUM-800
> URL: http://jira.codehaus.org/browse/CONTINUUM-800
> Project: Continuum
> Issue Type: Sub-task
>Reporter: Carlos Sanchez
> Attachments: CONTINUUM-800-continuum-webapp.patch,
> CONTINUUM-800-maven-user-model-testing.patch,
> CONTINUUM-800-maven-user-model-update-2.patch,
> CONTINUUM-800-maven-user-webapp-update-2.patch,
> CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch
>
>
> Added a first version of user management in
> https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user
> We have to move user code from Continuum there and use it instead
--
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
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=comments#action_73154
]
Carlos Sanchez commented on CONTINUUM-800:
--
applied. It may be that it doesn't work standalone, but we have to get it
working in continuum, and later in mrm
> Use maven-user project for user management
> --
>
> Key: CONTINUUM-800
> URL: http://jira.codehaus.org/browse/CONTINUUM-800
> Project: Continuum
> Issue Type: Sub-task
>Reporter: Carlos Sanchez
> Attachments: CONTINUUM-800-continuum-webapp.patch,
> CONTINUUM-800-maven-user-model-testing.patch,
> CONTINUUM-800-maven-user-model-update-2.patch,
> CONTINUUM-800-maven-user-webapp-update-2.patch,
> CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch
>
>
> Added a first version of user management in
> https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user
> We have to move user code from Continuum there and use it instead
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: index[new_nav_items].html
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> index[new_nav_items_w_top_right_quicklinks].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: (was: index[new_nav_items].html)
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> index[new_nav_items_w_top_right_quicklinks].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
continuum can get confused if wrong pom url is entered
--
Key: CONTINUUM-834
URL: http://jira.codehaus.org/browse/CONTINUUM-834
Project: Continuum
Issue Type: Bug
Components: Web interface
Affects Versions: 1.0.3
Reporter: Brett Porter
on codehaus, the following url was added as a pom:
http://svn.codehaus.org/livetribe/garden/livetribe-jsr223/trunk/pom.xml
this resulted in an HTML index file being downloaded as the file "trunk" to the
temp directory. It obviously fails, but when trying to add the correct
http://svn.codehaus.org/livetribe/garden/livetribe-jsr223/trunk/pom.xml, it
fails because trunk the directory can not be created.
We should remove the temp file if it previously failed.
--
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
temp files not cleaned up
-
Key: CONTINUUM-835
URL: http://jira.codehaus.org/browse/CONTINUUM-835
Project: Continuum
Issue Type: Bug
Components: Core system
Affects Versions: 1.0.3
Reporter: Brett Porter
there are thousands on maven-artifact.*.tmp files in the continuum temp
directory when using 1.0.3. It seems something is not using deleteOnExit
--
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
[ http://jira.codehaus.org/browse/MNG-2473?page=all ]
Marvin King updated MNG-2473:
-
Attachment: (was: index[new_nav_items_w_top_right_quicklinks].html)
> Improve Site Structuring
>
>
> Key: MNG-2473
> URL: http://jira.codehaus.org/browse/MNG-2473
> Project: Maven 2
> Issue Type: Task
> Components: Documentation: General
>Reporter: Marvin King
> Assigned To: Marvin King
> Attachments: index[new_nav_items].html,
> MNG-2473-site-[new_nav_items].patch,
> MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch
>
> Time Spent: 6 hours
> Remaining Estimate: 0 minutes
>
> See my proposal here:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL
> PROTECTED]
> See also:
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL
> PROTECTED]>
> Key to this is particularly changing the content of the front page, as well
> as the navigation.
--
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
