[jira] Closed: (MNG-2487) Dotnet Resources Support (code fix included)
[ http://jira.codehaus.org/browse/MNG-2487?page=all ]
Brett Porter closed MNG-2487.
-
Assignee: Brett Porter
Resolution: Fixed
applied and reviewed, with the exception of the comments on MCOMPILER-42 (and
likewise omission of the dotnet-resources plugin)
Dotnet Resources Support (code fix included)
Key: MNG-2487
URL: http://jira.codehaus.org/browse/MNG-2487
Project: Maven 2
Issue Type: Improvement
Components: Sandbox
Environment: Windows XP
Reporter: James Carpenter
Assigned To: Brett Porter
Attachments: masterzip.zip
The csharp plugins (currently in the sandbox) do not properly support csharp
resources. It turns out that solving the problem requires changing several
of the standard plugins. To resolve the problem I have made a few small
changes to the following code:
1) Created the maven-dotnet-resources-plugin.
This plugin is a clone of the standard resources plugin. The only real
change is to change the expression used in computing the output directory
within the @parameter tag of the Mojos. The output directory of the
maven-dotnet-resources-plugin points at a temporary directory down in
the target.
@parameter
expression=${project.build.directory}/csharp-workarea/dotnet-resources-plugin/resources
for the DotNetResourcesMojo, similar for the DotNetTestResourcesMojo
This is the same expression used for the filteredResourcesDirectory
instance variable in the modified maven-compiler-plugin.
Upon inspection the reader will soon realize the standard and dotnet
resources plugins should be somehow refactored so as to avoid
the gross copy/paste reuse.
2) maven-compiler-plugin
Added filteredResourcesDirectory and TestResourcesDirectory to the
CompilerMojo and TestCompilerMojo respectively. This is used to add a
resourceDir custom compiler configuration whenver the attributes point to
actual directories.
3) plexus-compiler-csharp
Added code to leverage the resourceDir compiler argument now being
passed down by the maven-compiler-plugin.
4) Modified the maven-csharp-lifecycle plugin
Changed META-INF/plexus/components.xml so as to replace
maven-resources-plugin with maven-dotnet-resources-plugin
Description from new maven-dotnet-resources-plugin (explains the overall
motivation):
The maven dotnet resources plugin is almost identical to the standard
resources plugin. The only difference is the result of
the resources and testResources goals are copied into special workarea
directories under target. Unlike javac which produces
a directory of class files which are typically archived in jar format by the
jar tool after javac has run, the csc (C# compiler) directly
produces an archive (a dll containing the dotnet assembly). Consequently,
csc must be passed each resource using the resource option. The
csharp compiler plugin and this plugin therefore collaborate. This dotnet
resources plugin places the resources in a temporary workarea under target
and the csharp compiler plugin produces resource option arguments to csc for
every file found there. You will notice all the filter support available in
the standard resources plugin is also available in the dotnet resources
plugin.
=
The attached maven-csharp plugins are currently set to SNAPSHOT as I havn't
yet created a new inhouse release for them. I'll probably do this as soon as
I finish this jira issue.
=
The attached zip file contains relevant patch files along with complete zips
of the code. You will notice the csharp plugins are slightly improved from
what is currently in the sandbox. To my knowledge the development of the
sandboxed csharp plugins is rather stagnated. There is probably enough code
here to bring the csharp plugins to an alpha release. I would much prefer to
be using officially released versions rather than having to maintain my own.
I am happy to have a half hour phone conversation with maven developer with
commit priviledges who can make this happen.
--
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-2656) Revised the Introduction to the POM
[ http://jira.codehaus.org/browse/MNG-2656?page=all ] Franz Allan Valencia See updated MNG-2656: -- Attachment: MNG-2656-maven-site.patch Revised the Introduction to the POM --- Key: MNG-2656 URL: http://jira.codehaus.org/browse/MNG-2656 Project: Maven 2 Issue Type: Improvement Components: Documentation: Introductions Reporter: Franz Allan Valencia See Priority: Minor Attachments: MNG-2656-maven-site.patch Revise the Minimal POM Discuss Project Inheritance further Add Discussion about Project Aggregation -- 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: (MNG-2656) Revised the Introduction to the POM
Revised the Introduction to the POM --- Key: MNG-2656 URL: http://jira.codehaus.org/browse/MNG-2656 Project: Maven 2 Issue Type: Improvement Components: Documentation: Introductions Reporter: Franz Allan Valencia See Priority: Minor Attachments: MNG-2656-maven-site.patch Revise the Minimal POM Discuss Project Inheritance further Add Discussion about Project Aggregation -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
Maven doesn't try to find snapshots in all repositories --- Key: MAVEN-1817 URL: http://jira.codehaus.org/browse/MAVEN-1817 Project: Maven 1.x Issue Type: Bug Components: core Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 In my environment I have several remote repositories. When Maven tries to update a snapshot, as soon as it found the snapshot on a given repo, it doesn't try to check if there's a more recent in another repo. -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=comments#action_79800 ]
Lukas Theussl commented on MAVEN-1817:
--
I can't seem to be able to reproduce anything these days ... or am I missing
something:
{noformat}
maven plugin:download
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
-DgroupId=maven -DartifactId=maven-xdoc-plugin -Dversion=1.10.1-SNAPSHOT
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT
build:start:
plugin:download-artifact:
[echo] repo is 'http://people.apache.org/repo/m1-snapshot-repository/'
[echo] trying to download
http://people.apache.org/repo/m1-snapshot-repository//maven/plugins/maven-xdoc-plugin-1.10.1-SNAPSHOT.jar
(211K)
[echo] repo is 'http://repo1.maven.org/maven'
[echo] trying to download
http://repo1.maven.org/maven/maven/plugins/maven-xdoc-plugin-1.10.1-SNAPSHOT.jar
plugin:download:
[delete] Deleting 1 files from /home/lukas/local/java/maven/trunk/plugins
[delete] /home/lukas/.maven/plugins not found.
[delete] Deleting 148 files from /home/lukas/.maven/cache
[delete] Deleted 15 directories from /home/lukas/.maven/cache
[copy] Copying 1 file to /home/lukas/local/java/maven/trunk/plugins
BUILD SUCCESSFUL
{noformat}
Maven doesn't try to find snapshots in all repositories
---
Key: MAVEN-1817
URL: http://jira.codehaus.org/browse/MAVEN-1817
Project: Maven 1.x
Issue Type: Bug
Components: core
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
Assigned To: Arnaud Heritier
Fix For: 1.1-rc1
In my environment I have several remote repositories.
When Maven tries to update a snapshot, as soon as it found the snapshot on a
given repo, it doesn't try to check if there's a more recent in another repo.
--
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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=all ] Arnaud Heritier updated MAVEN-1817: --- Comment: was deleted Maven doesn't try to find snapshots in all repositories --- Key: MAVEN-1817 URL: http://jira.codehaus.org/browse/MAVEN-1817 Project: Maven 1.x Issue Type: Bug Components: core Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 In my environment I have several remote repositories. When Maven tries to update a snapshot, as soon as it found the snapshot on a given repo, it doesn't try to check if there's a more recent in another repo. -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=comments#action_79802 ]
Arnaud Heritier commented on MAVEN-1817:
You're right. The plugin:download doesn't seem to reproduce this problem.
Can you try to build the multichanges plugin which has a SNAPSHOT dependency
actually. Here it's what I have :
{code}
$ maven
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT
Trying to get missing/snapshot dependencies required by Maven MultiChanges
Plugin:
Attempting to download maven-changes-plugin-1.7-SNAPSHOT.jar( groupid = maven,
artifactid = maven-changes-plugin, version = 1.7-SNAPSHOT, type = jar ).
Searching in repository : http://people.apache.org/repo/m1-snapshot-repository/
Required credentials not available for BASIC any realm@people.apache.org:80
Preemptive authentication requested but no default credentials available
Skipping download as local copy is up to date!
build:start:
plugin:plugin:
java:prepare-filesystem:
java:init:
java:compile:
[echo] Compiling to
c:\USERS\JTBox\projects\maven-1\plugins\multichanges/target/classes
java:jar-resources:
test:test:
[echo] No tests to run.
jar:jar:
[echo] Rewriting POM...
[copy] Copying 1 file to
C:\USERS\JTBox\projects\maven-1\plugins\multichanges\target
[jar] Updating jar:
C:\USERS\JTBox\projects\maven-1\plugins\multichanges\target\maven-multichanges-plugin-1.3-SNAPSHOT.jar
[delete] Deleting:
C:\USERS\JTBox\projects\maven-1\plugins\multichanges\target\project.xml
BUILD SUCCESSFUL
Total time : 5 seconds
Finished at : Friday, November 10, 2006 1:52:01 PM CET
{code]
Maven doesn't try to download the SNAPSHOT from : http://repo1.maven.org/maven
Maven doesn't try to find snapshots in all repositories
---
Key: MAVEN-1817
URL: http://jira.codehaus.org/browse/MAVEN-1817
Project: Maven 1.x
Issue Type: Bug
Components: core
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
Assigned To: Arnaud Heritier
Fix For: 1.1-rc1
In my environment I have several remote repositories.
When Maven tries to update a snapshot, as soon as it found the snapshot on a
given repo, it doesn't try to check if there's a more recent in another repo.
--
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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=comments#action_79803 ]
Arnaud Heritier commented on MAVEN-1817:
You're right. The plugin:download doesn't seem to reproduce this problem.
Can you try to build the multichanges plugin which has a SNAPSHOT dependency
actually. Here it's what I have :
{code}
$ maven
-Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/,http://repo1.maven.org/maven
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1-RC1-SNAPSHOT
Trying to get missing/snapshot dependencies required by Maven MultiChanges
Plugin:
Attempting to download maven-changes-plugin-1.7-SNAPSHOT.jar( groupid = maven,
artifactid = maven-changes-plugin, version = 1.7-SNAPSHOT, type = jar ).
Searching in repository : http://people.apache.org/repo/m1-snapshot-repository/
Required credentials not available for BASIC any realm@people.apache.org:80
Preemptive authentication requested but no default credentials available
Skipping download as local copy is up to date!
build:start:
plugin:plugin:
java:prepare-filesystem:
java:init:
java:compile:
[echo] Compiling to
c:\USERS\JTBox\projects\maven-1\plugins\multichanges/target/classes
java:jar-resources:
test:test:
[echo] No tests to run.
jar:jar:
[echo] Rewriting POM...
[copy] Copying 1 file to
C:\USERS\JTBox\projects\maven-1\plugins\multichanges\target
[jar] Updating jar:
C:\USERS\JTBox\projects\maven-1\plugins\multichanges\target\maven-multichanges-plugin-1.3-SNAPSHOT.jar
[delete] Deleting:
C:\USERS\JTBox\projects\maven-1\plugins\multichanges\target\project.xml
BUILD SUCCESSFUL
Total time : 5 seconds
Finished at : Friday, November 10, 2006 1:52:01 PM CET
{code}
Maven doesn't try to download the SNAPSHOT from : http://repo1.maven.org/maven
Maven doesn't try to find snapshots in all repositories
---
Key: MAVEN-1817
URL: http://jira.codehaus.org/browse/MAVEN-1817
Project: Maven 1.x
Issue Type: Bug
Components: core
Affects Versions: 1.1-beta-3
Reporter: Arnaud Heritier
Assigned To: Arnaud Heritier
Fix For: 1.1-rc1
In my environment I have several remote repositories.
When Maven tries to update a snapshot, as soon as it found the snapshot on a
given repo, it doesn't try to check if there's a more recent in another repo.
--
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-1678) missing element does not trigger any warning
[ http://jira.codehaus.org/browse/MNG-1678?page=all ] Vincent Siveton updated MNG-1678: - Fix Version/s: (was: 2.0.6) 2.0.5 in the same veine of MNG-1592 missing element does not trigger any warning Key: MNG-1678 URL: http://jira.codehaus.org/browse/MNG-1678 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0, 2.0.4 Reporter: Jorg Heymans Assigned To: Maria Odea Ching Fix For: 2.0.5 Original Estimate: 12 hours Remaining Estimate: 12 hours spot the subtle error in below pom : ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdorg.my.project/groupId artifactIdmyProject/artifactId version0.1/version nameThe Project/name packagingjar/packaging repositories repository idapache-maven2-snapshot/id nameApache Maven2 Snapshot Repository/name urlhttp://cvs.apache.org/maven-snapshot-repository/url /repository /repositories dependencies groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0-SNAPSHOT/version /dependencies /project The dependency element is missing inside dependencies. Maven did not give any warning or error though. Note that in my actual project, the dependency was not needed for compilation -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=comments#action_79806 ] Lukas Theussl commented on MAVEN-1817: -- Ok, I can reproduce that. :) I don't really know what's going on though, what is the difference with the former case? Maven doesn't try to find snapshots in all repositories --- Key: MAVEN-1817 URL: http://jira.codehaus.org/browse/MAVEN-1817 Project: Maven 1.x Issue Type: Bug Components: core Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 In my environment I have several remote repositories. When Maven tries to update a snapshot, as soon as it found the snapshot on a given repo, it doesn't try to check if there's a more recent in another repo. -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=comments#action_79808 ] Lukas Theussl commented on MAVEN-1817: -- Ok, I know what's the difference: plugin:download is still using the (deprecated) HttpUtils. So there is something to fix in Maven's DependencyVerifier class. Maven doesn't try to find snapshots in all repositories --- Key: MAVEN-1817 URL: http://jira.codehaus.org/browse/MAVEN-1817 Project: Maven 1.x Issue Type: Bug Components: core Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 In my environment I have several remote repositories. When Maven tries to update a snapshot, as soon as it found the snapshot on a given repo, it doesn't try to check if there's a more recent in another repo. -- 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: (MAVEN-1817) Maven doesn't try to find snapshots in all repositories
[ http://jira.codehaus.org/browse/MAVEN-1817?page=comments#action_79809 ] Arnaud Heritier commented on MAVEN-1817: ok. I'll try to fix it this WE. Thanks for the test. Maven doesn't try to find snapshots in all repositories --- Key: MAVEN-1817 URL: http://jira.codehaus.org/browse/MAVEN-1817 Project: Maven 1.x Issue Type: Bug Components: core Affects Versions: 1.1-beta-3 Reporter: Arnaud Heritier Assigned To: Arnaud Heritier Fix For: 1.1-rc1 In my environment I have several remote repositories. When Maven tries to update a snapshot, as soon as it found the snapshot on a given repo, it doesn't try to check if there's a more recent in another repo. -- 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-191) ${project.organization.name} is not evaluated in site.xml
[ http://jira.codehaus.org/browse/MSITE-191?page=comments#action_79815 ]
Martin Ahrer commented on MSITE-191:
The version of maven itself is 2.0.4 (version as published as last release
version)!
When ${project.organization.name} is used in site.xml exactly
${project.organization.name} is rendered to the HTML page - So I guess the
expression is not evaluated at all?
In my POM project.name is not equal to project.organization.name, they have
different names!
${project.organization.name} is not evaluated in site.xml
--
Key: MSITE-191
URL: http://jira.codehaus.org/browse/MSITE-191
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Reporter: Martin Ahrer
In a site.xml I'm trying to reference the project.organization.name element
from the POM. This expression is not evaluated properly when running the site
plugin for rendering a site! But for example the epxression ${project.name}
works fine!
--
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: (MASSEMBLY-159) Add FAQ about building multi-module assemblies from the top using Maven 2.0
Add FAQ about building multi-module assemblies from the top using Maven 2.0 --- Key: MASSEMBLY-159 URL: http://jira.codehaus.org/browse/MASSEMBLY-159 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: Maven 2.0 Reporter: Wendy Smoak John's post about why 'assembly:assembly' needs to be run separately with Maven 2.0 should be adapted for the FAQ. http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html Related Threads: http://www.nabble.com/Attaching-an-assembly-to-a-multi-module-project-t2608001s177.html http://www.nabble.com/HOWTO%3A-Have-assembly-plugin-call-package-automatically-before-doing-assembly--t2542444s177.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] Commented: (MSITE-135) inherited site.xml files are interpolated with the originating project's model values and not the consumer project's values
[ http://jira.codehaus.org/browse/MSITE-135?page=comments#action_79821 ]
John Allen commented on MSITE-135:
--
Hi Kenney,
Where do we stand on this? As far as i can tell the whole site inheritance
stuff is unusable due to all the bugs and strange behavours
inherited site.xml files are interpolated with the originating project's
model values and not the consumer project's values
---
Key: MSITE-135
URL: http://jira.codehaus.org/browse/MSITE-135
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Environment: 2.0.4
Reporter: John Allen
inherited site.xml files are interpolated with the originating project's
model values and not the consumer project's values
i have a n-deep multiproject env; when a sub-project uses the root project's
site.xml file, any ${project.*} expressions defined in the root site.xml are
replaced with values from the root project and not the project that is being
rendered, ie. title in index.html would be root project and not
sub-sub-sub-project. This applied to all ${project.*} expressions in 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-191) ${project.organization.name} is not evaluated in site.xml
[ http://jira.codehaus.org/browse/MSITE-191?page=comments#action_79822 ]
Vincent Siveton commented on MSITE-191:
---
OK I was thinking about another issue.
You right about the interpolation. See the TODO here:
http://maven.apache.org/plugins/maven-site-plugin/xref/org/apache/maven/plugins/site/AbstractSiteMojo.html#805
${project.organization.name} is not evaluated in site.xml
--
Key: MSITE-191
URL: http://jira.codehaus.org/browse/MSITE-191
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Reporter: Martin Ahrer
In a site.xml I'm trying to reference the project.organization.name element
from the POM. This expression is not evaluated properly when running the site
plugin for rendering a site! But for example the epxression ${project.name}
works fine!
--
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: (CONTINUUM-1001) Webapp build missing dependency
[ http://jira.codehaus.org/browse/CONTINUUM-1001?page=all ] Jesse McConnell closed CONTINUUM-1001. -- Resolution: Fixed Fix Version/s: 1.1 added this yesterday I think, thanks for the report Webapp build missing dependency --- Key: CONTINUUM-1001 URL: http://jira.codehaus.org/browse/CONTINUUM-1001 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Brian Topping Priority: Blocker Fix For: 1.1 Attachments: dep.patch Missing dependency, see attachment. -- 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: (CONTINUUM-798) Modules automatic discovery
[ http://jira.codehaus.org/browse/CONTINUUM-798?page=comments#action_79824 ] Jesse McConnell commented on CONTINUUM-798: --- #1 I am not too concerned about since we're due to fix that up soon #2 is a bit harder to accept since I would hazard that the majority of m2 builds involve submodules of that configuration I'll take a look through this though, thanks for the patch :) Modules automatic discovery --- Key: CONTINUUM-798 URL: http://jira.codehaus.org/browse/CONTINUUM-798 Project: Continuum Issue Type: Improvement Components: Core system Reporter: Nicolas Cazottes Attachments: add-modules-from-updated-project.diff In the case of using continuum with a parent POM that all projects inherit from, it should be a great feature to automatically discover addition of new modules and include them as projects in continuum. This is already done when the project is created the first time with its POM URL and the same mechanism should be used when continuum discovers that the pom has been updated. -- 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-2656) Revised the Introduction to the POM
[ http://jira.codehaus.org/browse/MNG-2656?page=comments#action_79825 ] Carlos Sanchez commented on MNG-2656: - The internal links don't work, and you probably don't need the name of the html page on them eg. introduction-to-the-pom.html#example_3 could be #Example 3 Revised the Introduction to the POM --- Key: MNG-2656 URL: http://jira.codehaus.org/browse/MNG-2656 Project: Maven 2 Issue Type: Improvement Components: Documentation: Introductions Reporter: Franz Allan Valencia See Priority: Minor Attachments: MNG-2656-maven-site.patch Revise the Minimal POM Discuss Project Inheritance further Add Discussion about Project Aggregation -- 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: (CONTINUUM-995) MavenTwoBuildExecutor.getDeployableArtifacts does not return attached artifacts
[ http://jira.codehaus.org/browse/CONTINUUM-995?page=comments#action_79826 ] Jesse McConnell commented on CONTINUUM-995: --- afaik -dist is not a standard assembly convention I pinged jcasey on it as well to make sure I wasn't missing the boat and he's not seen it either, that we remember at least. anyway, there is a big ole todo up there for getting maven to give us some information. jcasey actually mentioned that a continuum-maven-plugin that pushed this information into a specal descriptor might not be a bad idea. I just mention that so its mentioned somewhere. anyway, I don't think I can apply that patch right now... where did you get the -dist thing btw? I have seen -bin from assemblies but not -dist. thanks, and I'll keep this open though to track the discussion MavenTwoBuildExecutor.getDeployableArtifacts does not return attached artifacts --- Key: CONTINUUM-995 URL: http://jira.codehaus.org/browse/CONTINUUM-995 Project: Continuum Issue Type: Bug Reporter: John Didion Attachments: deploy-attached-artifacts.diff It only returns the main artifact for the project, and not any of the ones that get attached. This patch also adds a few more cases for -dist artifacts (assemblies). -- 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: (CONTINUUM-566) Build numbers are essential
[ http://jira.codehaus.org/browse/CONTINUUM-566?page=comments#action_79828 ] Jesse McConnell commented on CONTINUUM-566: --- added the build number to the common.vm mail template, but I'll leave this open for the ant script bit Build numbers are essential --- Key: CONTINUUM-566 URL: http://jira.codehaus.org/browse/CONTINUUM-566 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.0.2 Reporter: Bob Herrmann Attachments: add-build-number-to-mail-subject.diff Without a build number (and a sub-build number for failures - or repeat attempts) matching an email to a generated failure report is extremely difficult. For example, when using a ant project a with the junit-report tag, junit generates a complete listing of all failed unit tests per test run. With out a build number, matching a generated junit-report to a notification email is very difficult. -- 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: (MSITE-142) Velocity verbosity errors
[ http://jira.codehaus.org/browse/MSITE-142?page=all ] Dennis Lundberg closed MSITE-142. - Resolution: Duplicate Velocity verbosity errors - Key: MSITE-142 URL: http://jira.codehaus.org/browse/MSITE-142 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Linux Reporter: Frank Gutierrez Priority: Trivial This bug is about the importance of Maven's first impression. I'm a new user trying to follow the procedure in the book (better builds with maven) . I had two issues that made me wonder about the stability of the product. I love the ideas behind maven and I would hate to see the progress of the product slowed due to a bad first impression. #1) When issuing the archetype command it stopped in the middle of the procedure without an error message. I re-issued the command and it worked the second time around. $ mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app #2) When issuing the command mvn site there are ERROR messages that appear on the screen, again making me wonder about the stability of the product. See section of output below: [INFO] Velocimacro : initialization starting. [INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [site:site] [INFO] Generate Continuous Integration report. [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0 [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0 [INFO] Generate Dependencies report. -- 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-170) [ERROR] VM #displayTree: error : too few arguments to macro
[ http://jira.codehaus.org/browse/MSITE-170?page=comments#action_79832 ] Dennis Lundberg commented on MSITE-170: --- The issue in Velocity can now be found at this address: http://issues.apache.org/jira/browse/VELOCITY-71 It seems to have been resolved. I'll try to build the site plugin with a nightly build of Velocity, to see if it solves the issue in the site plugin. [ERROR] VM #displayTree: error : too few arguments to macro --- Key: MSITE-170 URL: http://jira.codehaus.org/browse/MSITE-170 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: fabrizio giustina when running mvn site:site a couple of too few arguments to macro always pop up. This is extremely bad in terms of user experience, and we should find a way to remove these logs: [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0 [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0 These errors are due to a known velocity bug related to the use of recursive macros: http://issues.apache.org/bugzilla/show_bug.cgi?id=13623 http://mail-archives.apache.org/mod_mbox/jakarta-velocity-user/200402.mbox/[EMAIL PROTECTED] Recursive macros are defined in org/apache/maven/doxia/siterenderer/resources/default-site.vm in the doxia site-renderer component. Logging is handled in the plexus velocity component. This velocity bug is still open in velocity and no patch will be available anytime soon. In the meanwhile we should try to handle this situation in some way by filtering out messages or removing the use of recursive macros (very hard, they are used to print out the site tree)... or switching to a better templating engine like freemarker. This issue could probably be addressed in the plexus velocity component or in the doxia site renderer (given that waiting for a bugfixed velocity release is not an option). I'm anyway assigning it to the site plugin since it's where users see these logs coming from and where probably users could open similar issues. Any suggestion on how to dirty-patch this? -- 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-1226) CLONE -synchronization script for org.slf4j
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1226?page=comments#action_79843 ] Ceki Gulcu commented on MAVENUPLOAD-1226: - Syncronisation with out repo has been done, it almost works but not quite. In our mvn repo, we have the following files: org/slf4j/ org/slf4j/slf4j-api org/slf4j/slf4j-api/maven-metadata.xml.sha1 org/slf4j/slf4j-api/maven-metadata.xml.md5 org/slf4j/slf4j-api/1.1.0-RC0 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0-tests.jar.md5 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0.jar.md5 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0.pom.md5 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0.jar.sha1 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0-tests.jar.sha1 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0.jar org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0.pom org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0-sources.jar.md5 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0-sources.jar org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0-tests.jar org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0.pom.sha1 org/slf4j/slf4j-api/1.1.0-RC0/slf4j-api-1.1.0-RC0-sources.jar.sha1 org/slf4j/slf4j-api/maven-metadata.xml org/slf4j/slf4j-jcl (and contents..) org/slf4j/slf4j-nop (and contents..) org/slf4j/jcl104-over-slf4j (and contents..) ... However, looking at http://www.ibiblio.org/maven2/org/slf4j, I observe that the syncronisation is done, but with one extra level of 'slf4j' in it, as can be seen at: http://www.ibiblio.org/maven2/org/slf4j/slf4j/slf4j-api/ If we could remove one level of slf4j, it would be much better. http://www.ibiblio.org/maven2/org/slf4j/slf4j/ A similar problem exists in for the logback project as can be seen at: http://www.ibiblio.org/maven2/ch/qos/logback/logback/ Is the above a problem on our side or a problem on yours? On a slightly different register, the following directory should be removed: http://www.ibiblio.org/maven2/ch/qos/logback/logback-access/$%7bparent.version%7d/ CLONE -synchronization script for org.slf4j --- Key: MAVENUPLOAD-1226 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1226 Project: maven-upload-requests Issue Type: Task Reporter: Ceki Gulcu Assigned To: Carlos Sanchez Please find the synchronization script with bundles published by slf4j.org in the attachments to this request. Please let me know if you encounter any problems. (It should work fine). -- 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-1226) CLONE -synchronization script for org.slf4j
CLONE -synchronization script for org.slf4j --- Key: MAVENUPLOAD-1226 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1226 Project: maven-upload-requests Issue Type: Task Reporter: Ceki Gulcu Assigned To: Carlos Sanchez Please find the synchronization script with bundles published by slf4j.org in the attachments to this request. Please let me know if you encounter any problems. (It should work fine). -- 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-170) [ERROR] VM #displayTree: error : too few arguments to macro
[ http://jira.codehaus.org/browse/MSITE-170?page=comments#action_79854 ] Dennis Lundberg commented on MSITE-170: --- Using the most recent nightly snapshot of Jakarta Velocity I did this: - Install the snapshot of Velocity 1.5 into my local repo - Update pom.xml for plexus-components/plexus-velocity to use velocity-1.5-dev, update commons-logging to 3.1 and add a dependency on commons-lang-2.1 - Install plexus-velocity 1.1.4-SNAPSHOT into local repo - Update pom.xml of doxia-siterenderer to use plexus-velocity 1.1.4-SNAPSHOT - Install doxia-siterenderer-1.0-alpha-9-SNAPSHOT into local repo - Install maven-site-plugin-2.0-SNAPSHOT built from source into local repo - Run 'mvn site' on any project. The errors about too many arguments to macro no longer appears. There are however quite a lot of warnings, that has not been there before :( [ERROR] VM #displayTree: error : too few arguments to macro --- Key: MSITE-170 URL: http://jira.codehaus.org/browse/MSITE-170 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: fabrizio giustina when running mvn site:site a couple of too few arguments to macro always pop up. This is extremely bad in terms of user experience, and we should find a way to remove these logs: [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0 [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0 These errors are due to a known velocity bug related to the use of recursive macros: http://issues.apache.org/bugzilla/show_bug.cgi?id=13623 http://mail-archives.apache.org/mod_mbox/jakarta-velocity-user/200402.mbox/[EMAIL PROTECTED] Recursive macros are defined in org/apache/maven/doxia/siterenderer/resources/default-site.vm in the doxia site-renderer component. Logging is handled in the plexus velocity component. This velocity bug is still open in velocity and no patch will be available anytime soon. In the meanwhile we should try to handle this situation in some way by filtering out messages or removing the use of recursive macros (very hard, they are used to print out the site tree)... or switching to a better templating engine like freemarker. This issue could probably be addressed in the plexus velocity component or in the doxia site renderer (given that waiting for a bugfixed velocity release is not an option). I'm anyway assigning it to the site plugin since it's where users see these logs coming from and where probably users could open similar issues. Any suggestion on how to dirty-patch this? -- 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: (MRM-186) rename depended on by to used by
[ http://jira.codehaus.org/browse/MRM-186?page=comments#action_79855 ] Brett Porter commented on MRM-186: -- I'd also like to change the terminology in the code references. Aren't you a committer now? :) rename depended on by to used by Key: MRM-186 URL: http://jira.codehaus.org/browse/MRM-186 Project: Archiva Issue Type: Improvement Components: web application Reporter: Brett Porter Fix For: 1.0 Attachments: MRM-186.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-204) Request for Documentation answers
[ http://jira.codehaus.org/browse/MRM-204?page=comments#action_79860 ] Henri Yandell commented on MRM-204: --- Validated User? Registered User? Can a user revalidate if they're invalidated? Can a the 'Need an account?' bit go away if you turn off guest access? Request for Documentation answers - Key: MRM-204 URL: http://jira.codehaus.org/browse/MRM-204 Project: Archiva Issue Type: Wish Reporter: Henri Yandell Could somebody explain what the following mean and are used for: Identifiers. Proxied Repositories. Observers. -- 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: (MRM-204) Request for Documentation answers
[ http://jira.codehaus.org/browse/MRM-204?page=comments#action_79862 ] Wendy Smoak commented on MRM-204: - Explain what each user role allows a user to do. * Registered User * User Administrator * System Administrator * Repository Manager - repo-id * Repository Observer - repo-id Request for Documentation answers - Key: MRM-204 URL: http://jira.codehaus.org/browse/MRM-204 Project: Archiva Issue Type: Wish Reporter: Henri Yandell Could somebody explain what the following mean and are used for: Identifiers. Proxied Repositories. Observers. -- 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: (MSITE-133) Fix documentation of skinning: groupId seems to be org.apache.maven.skins instead of org.apache.maven
[ http://jira.codehaus.org/browse/MSITE-133?page=all ] Dennis Lundberg closed MSITE-133. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0 This has been fixed in the source for http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html The howto.html page will be removed and/or redirected. Fix documentation of skinning: groupId seems to be org.apache.maven.skins instead of org.apache.maven --- Key: MSITE-133 URL: http://jira.codehaus.org/browse/MSITE-133 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: http://maven.apache.org/plugins/maven-site-plugin/howto.html Reporter: Jörg Hohwiller Assigned To: Dennis Lundberg Fix For: 2.0 At the bottom of the page: http://maven.apache.org/plugins/maven-site-plugin/howto.html the wrong groupId is specified. Should be org.apache.maven.skins. -- 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: (MSITE-151) Ability to change the site directory in the plugin configuration in the pom.xml file.
[ http://jira.codehaus.org/browse/MSITE-151?page=all ] Dennis Lundberg closed MSITE-151. - Resolution: Duplicate Ability to change the site directory in the plugin configuration in the pom.xml file. - Key: MSITE-151 URL: http://jira.codehaus.org/browse/MSITE-151 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-5 Environment: All Reporter: Mark Soderquist Fix For: 2.0 Attachments: AbstractSiteMojo.diff Added the ability to change the site directory via the plugin configuration in the pom.xml file. This completes an existing TODO in the code. Attached is the SVN diff file for the 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] Closed: (MSITE-91) src/site/site.xml hardcoded in AbstractSiteMojo.java
[ http://jira.codehaus.org/browse/MSITE-91?page=all ]
Dennis Lundberg closed MSITE-91.
Assignee: Dennis Lundberg (was: Brett Porter)
Resolution: Fixed
Fix Version/s: 2.0
src/site/site.xml hardcoded in AbstractSiteMojo.java
--
Key: MSITE-91
URL: http://jira.codehaus.org/browse/MSITE-91
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Fabrice BELLINGARD
Assigned To: Dennis Lundberg
Fix For: 2.0
Attachments: MSITE-91.patch
There's a todo in the code, so this issue is more a reminder than an unknown
bug.
In AbstractSiteMojo.java, there's:
protected File getSiteDescriptorFile( File basedir, Locale locale )
{
// TODO: get proper siteDirectory from site configuration of the
project this relates to
File siteDescriptor = new File( basedir, src/site/site_ +
locale.getLanguage() + .xml );
if ( !siteDescriptor.exists() )
{
siteDescriptor = new File( basedir, src/site/site.xml );
}
return siteDescriptor;
}
--
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: (MSITE-118) Provide a schema for site.xml
[ http://jira.codehaus.org/browse/MSITE-118?page=all ] Dennis Lundberg updated MSITE-118: -- Affects Version/s: (was: 2.0) 2.0-beta-5 Provide a schema for site.xml - Key: MSITE-118 URL: http://jira.codehaus.org/browse/MSITE-118 Project: Maven 2.x Site Plugin Issue Type: Wish Affects Versions: 2.0-beta-5 Reporter: Wendy Smoak Priority: Minor Fix For: 2.0 Brett mentioned that a schema for site.xml will be available with maven-site-plugin 2.0 final. Just logging a reminder issue as I don't see it in svn or at http://maven.apache.org/xsd/ . http://mail-archives.apache.org/mod_mbox/maven-users/200602.mbox/[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: (MSITE-118) Provide a schema for site.xml
[ http://jira.codehaus.org/browse/MSITE-118?page=comments#action_79868 ] Dennis Lundberg commented on MSITE-118: --- I thought that I'd have a go at this. There is a schema available for the Maven 1 xdoc plugin, that I will use as a starting ground. It can be found here: http://maven.apache.org/maven-1.x/plugins/xdoc/maven-navigation.xsd Should we generate the schema for site.xml using modello? Provide a schema for site.xml - Key: MSITE-118 URL: http://jira.codehaus.org/browse/MSITE-118 Project: Maven 2.x Site Plugin Issue Type: Wish Affects Versions: 2.0-beta-5 Reporter: Wendy Smoak Priority: Minor Fix For: 2.0 Brett mentioned that a schema for site.xml will be available with maven-site-plugin 2.0 final. Just logging a reminder issue as I don't see it in svn or at http://maven.apache.org/xsd/ . http://mail-archives.apache.org/mod_mbox/maven-users/200602.mbox/[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] Updated: (MNG-2656) Revised the Introduction to the POM
[ http://jira.codehaus.org/browse/MNG-2656?page=all ] Franz Allan Valencia See updated MNG-2656: -- Attachment: MNG-2656-maven-site-2.patch Good day to you, Carlos, Sorry about that. I've now tested this patch with org.apache.maven.plugins:maven-site-plugin:2.0-beta-5. I guess I was using an 2.0-SNAPSHOT before. Btw, I forgot to mention that this is not yet final. As to what else is lacking is probably a recheck. Recheck if this contains enough information to get someone started creating a POM, and as an introdcution of other pom references such as [1] and [2]. Also, a recheck whether this contains to much of an information for an introductory documentation. It would be nice if this would be reviewed. Thanks, Franz Revised the Introduction to the POM --- Key: MNG-2656 URL: http://jira.codehaus.org/browse/MNG-2656 Project: Maven 2 Issue Type: Improvement Components: Documentation: Introductions Reporter: Franz Allan Valencia See Priority: Minor Attachments: MNG-2656-maven-site-2.patch, MNG-2656-maven-site.patch Revise the Minimal POM Discuss Project Inheritance further Add Discussion about Project Aggregation -- 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: (CONTINUUM-995) MavenTwoBuildExecutor.getDeployableArtifacts does not return attached artifacts
[ http://jira.codehaus.org/browse/CONTINUUM-995?page=comments#action_79870 ] John Didion commented on CONTINUUM-995: --- -dist is a loose standard we decided on internally for installable assemblies (as opposed to -bin, which typically implies a library packaged up with documentation and such). I really just put it in there as a placeholder...I don't really care what the extension is, as long as Continuum is capable of recognizing assemblies and putting them in the repository. Ideally, the extensions that Continuum deploys would be configurable. If you have a better solution in the works, that's fine...we'll just continue using our hacked version of Continuum until it's ready. MavenTwoBuildExecutor.getDeployableArtifacts does not return attached artifacts --- Key: CONTINUUM-995 URL: http://jira.codehaus.org/browse/CONTINUUM-995 Project: Continuum Issue Type: Bug Reporter: John Didion Attachments: deploy-attached-artifacts.diff It only returns the main artifact for the project, and not any of the ones that get attached. This patch also adds a few more cases for -dist artifacts (assemblies). -- 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-2656) Revised the Introduction to the POM
[ http://jira.codehaus.org/browse/MNG-2656?page=comments#action_79871 ] Franz Allan Valencia See commented on MNG-2656: --- Pardon, i forgot the references... [1] http://maven.apache.org/pom.html [2] http://maven.apache.org/ref/current/maven-model/maven.html Revised the Introduction to the POM --- Key: MNG-2656 URL: http://jira.codehaus.org/browse/MNG-2656 Project: Maven 2 Issue Type: Improvement Components: Documentation: Introductions Reporter: Franz Allan Valencia See Priority: Minor Attachments: MNG-2656-maven-site-2.patch, MNG-2656-maven-site.patch Revise the Minimal POM Discuss Project Inheritance further Add Discussion about Project Aggregation -- 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
