[jira] Created: (MNG-1731) I18n issues with report generation

2005-12-02 Thread Anuerin Diaz (JIRA)
I18n issues with report generation
--

 Key: MNG-1731
 URL: http://jira.codehaus.org/browse/MNG-1731
 Project: Maven 2
Type: Wish
Versions: 2.0
Reporter: Anuerin Diaz


The issue wherein report generation of certain plugins (or mix) causes the 
site/build phase to fail has already been logged before (see 
http://jira.codehaus.org/browse/MNG-1572). It might be better for the report 
component to have a way of falling back to a default  locale especially when 
the locale was not explicitly defined in the project descriptor. 

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (MNG-983) add staging site capabilities

2005-12-02 Thread Anuerin Diaz (JIRA)
[ http://jira.codehaus.org/browse/MNG-983?page=comments#action_52646 ] 

Anuerin Diaz commented on MNG-983:
--

Does staging means that there is a separate directory for the assembly of all 
site documentation? I have a need for a way to configure an alternate site 
directory since the site:deploy goal scatters all the pages on the distribution 
site.

Thanks.

ciao!

> add staging site capabilities
> -
>
>  Key: MNG-983
>  URL: http://jira.codehaus.org/browse/MNG-983
>  Project: Maven 2
> Type: Improvement
>   Components: maven-site-plugin
> Reporter: Brett Porter

>
>


-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1673) Improper APT tags? (Guide to release plugin)

2005-11-24 Thread Anuerin Diaz (JIRA)
Improper APT tags? (Guide to release plugin)


 Key: MNG-1673
 URL: http://jira.codehaus.org/browse/MNG-1673
 Project: Maven 2
Type: Bug
  Components: documentation - guides  
Reporter: Anuerin Diaz
Priority: Trivial


The guide found in http://maven.apache.org/guides/mini/guide-releasing.html 
seems to have incorrect APT formatting since the first part is shown as 
verbatim text when they should already been showing the start of the guide. The 
incorrect formatting ends up to the mvn release:prepare example (where the 
verbatic notation was only done using a single hyphen).

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1652) Placeholder task for missing project reports

2005-11-22 Thread Anuerin Diaz (JIRA)
Placeholder task for missing project reports


 Key: MNG-1652
 URL: http://jira.codehaus.org/browse/MNG-1652
 Project: Maven 2
Type: Wish
  Components: maven-site-plugin  
Versions: 2.0
 Environment: Windows XP Professional, Maven 2.0, maven-javadoc-plugin 
v2.0-beta-2, maven-clover-plugin v2.0-alpha
Reporter: Anuerin Diaz


Related to http://jira.codehaus.org/browse/MNG-1611, most (I have not tested) 
report plugin will not generate a placeholder page if the current project does 
not meet the requirements (source codes in javadoc, testcases in clover, etc). 
This is especially true for pom projects that serves as integration projects. 
The final site still has a link to the supposedly report page but this will 
cause a 404 error since the page is not really generated.

Currently I can see two options:

1. The site navigation generator will omit the menu report items if the page 
does not exist.
2. Each respective plugin will generate a placeholder page if the current 
project does not meet the requirement.

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1611) clover should generate a placeholder if project do not have test cases

2005-11-18 Thread Anuerin Diaz (JIRA)
clover should generate a placeholder if project do not have test cases
--

 Key: MNG-1611
 URL: http://jira.codehaus.org/browse/MNG-1611
 Project: Maven 2
Type: Improvement
  Components: maven-clover-plugin  
Versions: 2.0
 Environment: Maven 2.0, maven.clover-plugin 2.0-alpha-1
Reporter: Anuerin Diaz


For project that have no test cases (like parent projects of packaging type 
pom), the generated site contains a Clover link under the "Project Reports" 
menu but since coverage testing results was not generated for this project then 
the link points to a non-existent page.

In cases like this, it would be nice to have a placeholder page (one saying the 
tests were not applicable), or the actual clover link removed  so that the 
users will not click onto a missing link.

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1610) locale parameter causes javadoc to fail

2005-11-18 Thread Anuerin Diaz (JIRA)
locale parameter causes javadoc to fail
---

 Key: MNG-1610
 URL: http://jira.codehaus.org/browse/MNG-1610
 Project: Maven 2
Type: Bug
  Components: maven-javadoc-plugin  
Versions: 2.0
 Environment: Maven 2.0, maven-javadoc-plugin v2.0-beta-2
Reporter: Anuerin Diaz


Using the following configuration


   org.apache.maven.plugins
   maven-javadoc-plugin
   
  en_US
   


the javadoc execution fails with:

[INFO] An error has occurred in JavaDocs report generation.

Embedded error: Exit code: 1 - javadoc: option -locale must be first on the 
command line.



-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (MNG-1572) Locale problem in Clover plugin

2005-11-18 Thread Anuerin Diaz (JIRA)
[ http://jira.codehaus.org/browse/MNG-1572?page=comments#action_51311 ] 

Anuerin Diaz commented on MNG-1572:
---

since it is related, i will quote portions of  my email to the user's list:

=
my second issue with the javadoc plugin when it is used together with the 
clover plugin. the javadoc plugin is causing the clover-plugin to fail. used on 
its own the clover plugin works fine but if i declare the javadoc and clover 
plugins at the same time then the clover plugin will fail with a "Can't find 
bundle for base name clover-report, locale fi_FI".  changing the regional 
settings of my workstation to en_US provides a temporary solution but not 
something
that management will endorse. as far as i can see the clover plugin does not 
have a configuration setting for locale, and i am still confused why this 
problem will only surface if the javadoc plugin is also activated.




> Locale problem in Clover plugin
> ---
>
>  Key: MNG-1572
>  URL: http://jira.codehaus.org/browse/MNG-1572
>  Project: Maven 2
> Type: Bug
>   Components: maven-clover-plugin
> Versions: 2.0
> Reporter: Wim Deblauwe

>
>
> I get the following error with the clover plugin
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Can't find bundle for base name clover-report, locale nl_NL
> [INFO] 
> 
> [INFO] Trace
> java.util.MissingResourceException: Can't find bundle for base name 
> clover-report, locale nl_NL
> at 
> java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:700)
> at 
> org.apache.maven.plugin.clover.CloverReportMojo.getBundle(CloverReportMojo.java:104)
> at 
> org.apache.maven.plugin.clover.CloverReportMojo.getName(CloverReportMojo.java:136)
> at 
> org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40)
> at java.util.Arrays.mergeSort(Arrays.java:1284)
> at java.util.Arrays.sort(Arrays.java:1223)
> at java.util.Collections.sort(Collections.java:159)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> regards,
> Wim

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1554) Assembly plugin fails to resolve dependency when it tries to package the application

2005-11-14 Thread Anuerin Diaz (JIRA)
Assembly plugin fails to resolve dependency when it tries to package the 
application


 Key: MNG-1554
 URL: http://jira.codehaus.org/browse/MNG-1554
 Project: Maven 2
Type: Bug
  Components: maven-assembly-plugin  
Versions: 2.0
 Environment: windows XP Prof, Maven 2.0, maven-assembly-plugin 2.0
Reporter: Anuerin Diaz


When invoking goals in the assembly plugin, it tries to build the application 
modules. However it fails when trying to resolve the dependencies because the 
artifacts of the base modules are not yet installed in the local repository. It 
seems that the plugin is not able to read the reactor/storage that tthe normal 
compiler environment uses. 

Issuing the package command on the project works so the fix should be such that 
the assembly plugin utilitze the same mechanism that "mvn package" uses for 
building the application, or else dont attempt to build the application and 
just assume that the artifacts are already built and only needs to be packaged 
as described in the "assembly descriptor".

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Closed: (MNG-1526) NoClassDefFound when unit tests are being executed

2005-11-14 Thread Anuerin Diaz (JIRA)
 [ http://jira.codehaus.org/browse/MNG-1526?page=all ]
 
Anuerin Diaz closed MNG-1526:
-

Resolution: Incomplete

I have decided to close this issue for the mean time until I have more 
information. This is in relation to the discussion in 
http://www.mail-archive.com/users@maven.apache.org/msg27931.html



> NoClassDefFound when unit tests are being executed
> --
>
>  Key: MNG-1526
>  URL: http://jira.codehaus.org/browse/MNG-1526
>  Project: Maven 2
> Type: Bug
>   Components: maven-surefire-plugin
> Versions: 2.0
>  Environment: Windows XP Professional/ Maven 2.0
> Reporter: Anuerin Diaz

>
>
>Surefire is failing on its execution and from what I can surmise from the 
> error is that maven tries to run the non-existent
> "org.codehaus.surefire.Runner" class. I already opened up the 1.3 and 1.4 
> surefire group of jar files and there is really no Runner class in there.
>   Is there a special step or requirement to run test cases in maven? The 
> JUnit tests run fine from the Ant JUnit task. The stacktrace is shown below.
> ---
>  T E S T S
> ---
> java.lang.NoClassDefFoundError
>at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
>at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
>at java.lang.Class.newInstance0(Class.java:308)
>at java.lang.Class.newInstance(Class.java:261)
>at com.meridea.cs.logging.Logger.getDelegatePlugin(Logger.java:306)
>at com.meridea.cs.logging.Logger.(Logger.java:64)
>at com.meridea.cs.logging.Logger.getLogger(Logger.java:285)
>at 
> test.com.meridea.cs.charfilter.AllowedCharacterFilterTest.(AllowedCharacterFilterTest.java:23)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:324)
>at 
> org.codehaus.surefire.battery.JUnitBattery.(JUnitBattery.java:134)
>at 
> org.codehaus.surefire.Surefire.instantiateBatteries(Surefire.java:318)
>at org.codehaus.surefire.Surefire.run(Surefire.java:130)
>at org.codehaus.surefire.Surefire.run(Surefire.java:77)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:324)
>at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104)
>at 
> org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:303)
>at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
>at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
>at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
>at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
>at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301
> )
>at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
>at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
>at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:324)
>at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> RUN ABORTED
> java.lang.NoClassDefFoundError
> org.codehaus.surefir

[jira] Created: (MNG-1526) NoClassDefFound when unit tests are being executed

2005-11-12 Thread Anuerin Diaz (JIRA)
NoClassDefFound when unit tests are being executed
--

 Key: MNG-1526
 URL: http://jira.codehaus.org/browse/MNG-1526
 Project: Maven 2
Type: Bug
  Components: maven-surefire-plugin  
Versions: 2.0
 Environment: Windows XP Professional/ Maven 2.0
Reporter: Anuerin Diaz


   Surefire is failing on its execution and from what I can surmise from the 
error is that maven tries to run the non-existent
"org.codehaus.surefire.Runner" class. I already opened up the 1.3 and 1.4 
surefire group of jar files and there is really no Runner class in there.

  Is there a special step or requirement to run test cases in maven? The JUnit 
tests run fine from the Ant JUnit task. The stacktrace is shown below.



---
 T E S T S
---
java.lang.NoClassDefFoundError
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
   at java.lang.Class.newInstance0(Class.java:308)
   at java.lang.Class.newInstance(Class.java:261)
   at com.meridea.cs.logging.Logger.getDelegatePlugin(Logger.java:306)
   at com.meridea.cs.logging.Logger.(Logger.java:64)
   at com.meridea.cs.logging.Logger.getLogger(Logger.java:285)
   at 
test.com.meridea.cs.charfilter.AllowedCharacterFilterTest.(AllowedCharacterFilterTest.java:23)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at 
org.codehaus.surefire.battery.JUnitBattery.(JUnitBattery.java:134)
   at org.codehaus.surefire.Surefire.instantiateBatteries(Surefire.java:318)
   at org.codehaus.surefire.Surefire.run(Surefire.java:130)
   at org.codehaus.surefire.Surefire.run(Surefire.java:77)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104)
   at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:303)
   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301
)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:324)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
RUN ABORTED
java.lang.NoClassDefFoundError
org.codehaus.surefire.Runner
An exception or error caused a run to abort.
null

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1521) Maximize the use of the Apache wiki page for Maven

2005-11-11 Thread Anuerin Diaz (JIRA)
Maximize the use of the Apache wiki page for Maven
--

 Key: MNG-1521
 URL: http://jira.codehaus.org/browse/MNG-1521
 Project: Maven 2
Type: Task
  Components: documentation - general  
Reporter: Anuerin Diaz


>From the Maven user list (Alexander Hars)

Hi,

I have been using Maven2 for two weeks and am very impressed by all the
great features.

However, the learning curve is steep and it is often very difficult to
find certain answers (I often need to
to look at the source code to find them). Whenever I find an answer to a
question, I alone have learned.
Others don't profit. I would be quite willing to submit an answer to
Maven2 for inclusion into the guides. But that takes
quite a bit of time (...going into CVS, downloading the apt file,
modifying it, testing it, submitting it to someone for posting
to the CVS etc.). I did that once, but we can't expect big progress in
the documentation to occur this way.

The only solution that does not overload the developers (who put in so
much time already anyhow), is  to make better use
of the wiki because everybody can contribute and increase our cumulated
knowledge. But just providing the wiki as
it is now (http://wiki.apache.org/maven/Maven2Info) does not work. There
is almost nothing there, almost nobody
goes to it, therefore few people add anything either.

There are two practical ways in which we could make better use of the wiki:

a) provide a prominent link from the Maven2 documentation (guides,
miniguides, references, etc.) to a related wiki
page. Anyone who has some insight to add to the documentation can place
it there; anyone who has not found the
answer in the standard documentation can easily check whether there is
more information in the wiki. From time
to time someone can integrate the bulk of good insights from the wiki
back into the documentation.

b) put most of the documentation into the wiki. In my opinion this is
the ideal case, because it would reduce the
load on the developers for providing the documentation and there would
be a single documentation mechanism.
But it is probably not practical because the Maven Wiki is not based on
the .apt format and integration with the
maven site generation mechanism may be difficult.

Option a) is very easy to do. We would only need to create associated
wiki pages and insert a link to the wiki
page from the original documentation. I am sure that we could greatly
expand the Maven-related knowledge
this way.

I certainly would be willing to work on the necessary changes to get
this rolling if you think this is a good idea.




-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1520) Excluding pom.properties and pom.xml from produced artifact

2005-11-11 Thread Anuerin Diaz (JIRA)
Excluding pom.properties and pom.xml from produced artifact 


 Key: MNG-1520
 URL: http://jira.codehaus.org/browse/MNG-1520
 Project: Maven 2
Type: Wish
  Components: maven-jar-plugin  
Reporter: Anuerin Diaz


Although the files are supposed to be used in capturing as much build 
information as necessary, they are considered to be a security risk in some 
situations. There must be a way to exclude these files even during development 
packaging. 

The released Maven plugins do not contain these files so there is a way to 
remove them. The following configuration do not work when added to the project 
descriptor:


   maven-jar-plugin
   
  **/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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1519) Support for mappers in assembly desriptors

2005-11-11 Thread Anuerin Diaz (JIRA)
Support for mappers in assembly desriptors
--

 Key: MNG-1519
 URL: http://jira.codehaus.org/browse/MNG-1519
 Project: Maven 2
Type: Wish
  Components: maven-assembly-plugin  
Reporter: Anuerin Diaz


I would like to forward a wish to have the assembly plugin support the notion 
of file mappers similar to the ones in Ant[1]. To illustrate, assuming a 
multi-module project with the following layout:

 Root
   |-Module1
   |-Module2
   |-Container
   |  |-Module3
   |  |-Module4
   |-Module5
   |- pom.xml

and an assembly desriptor entry for the contained modules like this

  
 
Container


  **/target/*.jar

 
  

The assembly plugin will be able to get all jar files produced by Module3 and 
Module4 but the "Container//target" structure will still be 
included. One workaround is to enumerate each  artifact but 
problematic if the number of contained sub-modules is numerous. Support for 
filemappers which  look like this:

  
 
Container


  **/target/*.jar


 
  

will cause all contained jar files to be copied without their original 
structure. This feature would be useful for globbing artifact names as well as 
for physically organizing project structures according to type.

[1] http://ant.apache.org/manual/CoreTypes/mapper.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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Closed: (MNG-1518) Capability to specify the layout of the artifacts being assembled

2005-11-11 Thread Anuerin Diaz (JIRA)
 [ http://jira.codehaus.org/browse/MNG-1518?page=all ]
 
Anuerin Diaz closed MNG-1518:
-

Resolution: Won't Fix

The  element of the  element of the assembly 
descriptor is useful for this purpose.

> Capability to specify the layout of the artifacts being assembled
> -
>
>  Key: MNG-1518
>  URL: http://jira.codehaus.org/browse/MNG-1518
>  Project: Maven 2
> Type: New Feature
>   Components: maven-assembly-plugin
> Reporter: Anuerin Diaz
> Priority: Minor

>
>
> Could there be a way to allow the assembly descriptor file to specify how the 
> artifacts being assembled are copied to the assembly area? I am thinking 
> something to the likes of grouping certain artifacts together similar to the 
> following
> target
>|-${project.finalname}-package
>|  |-${project.finalname}
>|  |  |-common
>|  |  |   |-artifact1.jar
>|  |  |   |-artifact2.jar
>|  |  |   
>|  |  |-client
>|  |  |   |- ...
>|  |  |   
>|  |  |-server
>|  |  |   |- ...
>|  |  |   
>|  |  |-config
>|  |  |   |- screens
>|  |  |   |- otherobjects
> Currently the assembly just dumps everything on the ${project.finalname} 
> folder.

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1518) Capability to specify the layout of the artifacts being assembled

2005-11-11 Thread Anuerin Diaz (JIRA)
Capability to specify the layout of the artifacts being assembled
-

 Key: MNG-1518
 URL: http://jira.codehaus.org/browse/MNG-1518
 Project: Maven 2
Type: New Feature
  Components: maven-assembly-plugin  
Reporter: Anuerin Diaz
Priority: Minor


Could there be a way to allow the assembly descriptor file to specify how the 
artifacts being assembled are copied to the assembly area? I am thinking 
something to the likes of grouping certain artifacts together similar to the 
following

target
   |-${project.finalname}-package
   |  |-${project.finalname}
   |  |  |-common
   |  |  |   |-artifact1.jar
   |  |  |   |-artifact2.jar
   |  |  |   
   |  |  |-client
   |  |  |   |- ...
   |  |  |   
   |  |  |-server
   |  |  |   |- ...
   |  |  |   
   |  |  |-config
   |  |  |   |- screens
   |  |  |   |- otherobjects

Currently the assembly just dumps everything on the ${project.finalname} folder.

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Closed: (MNG-1492) A more in-depth guide on the elements of the Project descriptor (pom.xml) file.

2005-11-10 Thread Anuerin Diaz (JIRA)
 [ http://jira.codehaus.org/browse/MNG-1492?page=all ]
 
Anuerin Diaz closed MNG-1492:
-

Resolution: Duplicate

> A more in-depth guide on the elements of the Project descriptor (pom.xml) 
> file.
> ---
>
>  Key: MNG-1492
>  URL: http://jira.codehaus.org/browse/MNG-1492
>  Project: Maven 2
> Type: Improvement
>   Components: documentation - guides
> Reporter: Anuerin Diaz

>
>
> Currently the documentation[1] on the Project descriptor file is sparse. 
> Although most of the basic elements are understandable[2], some of the 
> features remain under utilized (e.g. difference between dependencies and 
> dependencyManagement, plugins and pluginsManagement, etc.).
> A more in-depth explanation or discussion on what are the advantages of each 
> element may be in order. Hopefully the user community can also contribute so 
> that it would be easier to write the guide.
> [1] http://maven.apache.org/maven-model/maven.html
> [2] http://maven.apache.org/guides/introduction/introduction-to-the-pom.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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (MNG-1502) FAQ submission: Missing plugin

2005-11-10 Thread Anuerin Diaz (JIRA)
[ http://jira.codehaus.org/browse/MNG-1502?page=comments#action_50593 ] 

Anuerin Diaz commented on MNG-1502:
---

Or change the last sentence to the following (I cant seem to find the link to 
edit submitted issues):

=
If the problem still persists you may seek help from the Maven user list, http://www.mail-archive.com/users@maven.apache.org/";>browse the 
archives or http://jira.codehaus.org/browse/MNG";>log a ticket 
describing your problem. 


The search functionality on mail-archive.org is easier to use than nabble which 
is why I prefer it.

ciao!


> FAQ submission: Missing plugin
> --
>
>  Key: MNG-1502
>  URL: http://jira.codehaus.org/browse/MNG-1502
>  Project: Maven 2
> Type: Improvement
>   Components: documentation - faqs
> Reporter: Anuerin Diaz

>
>
> Hi,
>Since this is a common occurence especially for new users, it might be 
> beneficial including a FAQ entry similar to the following:
> =
> Why am I getting a " does not exist or no valid version" error?
> This means that Maven is unable to access the required plugin from your local 
> repository, and unable to access the official or 'central' Maven2 plugin 
> repository.
> You may troubleshoot the problem by performing the following actions:
> 
> 
> If you are behind a http proxy, please check the Maven2  href="http://maven.apache.org/guides/mini/guide-proxies.html";>proxy settings 
> guide.
> 
> 
> If the plugin you seek cannot be redistributed freely then you may  href="http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html";>add
>  it manually to your repository.
> 
> 
> If the problem still persists you may seek help from the Maven user list, or 
> http://jira.codehaus.org/browse/MNG";>log a ticket describing 
> your problem.
> =

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1502) FAQ submission: Missing plugin

2005-11-10 Thread Anuerin Diaz (JIRA)
FAQ submission: Missing plugin
--

 Key: MNG-1502
 URL: http://jira.codehaus.org/browse/MNG-1502
 Project: Maven 2
Type: Improvement
  Components: documentation - faqs  
Reporter: Anuerin Diaz


Hi,

   Since this is a common occurence especially for new users, it might be 
beneficial including a FAQ entry similar to the following:

=
Why am I getting a " does not exist or no valid version" error?

This means that Maven is unable to access the required plugin from your local 
repository, and unable to access the official or 'central' Maven2 plugin 
repository.

You may troubleshoot the problem by performing the following actions:


If you are behind a http proxy, please check the Maven2 http://maven.apache.org/guides/mini/guide-proxies.html";>proxy settings 
guide.


If the plugin you seek cannot be redistributed freely then you may http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html";>add 
it manually to your repository.



If the problem still persists you may seek help from the Maven user list, or http://jira.codehaus.org/browse/MNG";>log a ticket describing your 
problem.
=

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (MNG-1479) Improve pom annotations to create a great reference

2005-11-10 Thread Anuerin Diaz (JIRA)
[ http://jira.codehaus.org/browse/MNG-1479?page=comments#action_50577 ] 

Anuerin Diaz commented on MNG-1479:
---

taken from http://jira.codehaus.org/browse/MNG-1492 (duplicate entry)

=
Currently the documentation[1] on the Project descriptor file is sparse. 
Although most of the basic elements are understandable[2], some of the features 
remain under utilized (e.g. difference between dependencies and 
dependencyManagement, plugins and pluginsManagement, etc.).

A more in-depth explanation or discussion on what are the advantages of each 
element may be in order. Hopefully the user community can also contribute so 
that it would be easier to write the guide.

[1] http://maven.apache.org/maven-model/maven.html
[2] http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
=

> Improve pom annotations to create a great reference
> ---
>
>  Key: MNG-1479
>  URL: http://jira.codehaus.org/browse/MNG-1479
>  Project: Maven 2
> Type: Improvement
>   Components: documentation - general
> Versions: 2.0
>  Environment: n/a
> Reporter: Jeff Jensen

>
>
> Besides the multi-module doc, my experience wishes for the POM entry 
> descriptions - some are too vague.  More detail (what is it for/why would you 
> use it, how to use it), examples, valid values, etc. would help a lot.
> I think the project descriptor has big potential as a solid reference 
> vehicle, with the added info.  I would value that more than many of the 
> "guides".
> For a simple example, the  element doesn't describe valid values, 
> so a search begins to learn them.  Viewing the schema doesn't help, as the 
> packaging type is "string".  Additionally, I think the phrase "type of 
> artifact" is not intuitive to newbies, so listing the valid values would 
> bring contextual explanation, as well as their definition.
> (from http://mail-archives.apache.org/mod_mbox/maven-users/200511.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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (MNG-1492) A more in-depth guide on the elements of the Project descriptor (pom.xml) file.

2005-11-10 Thread Anuerin Diaz (JIRA)
[ http://jira.codehaus.org/browse/MNG-1492?page=comments#action_50575 ] 

Anuerin Diaz commented on MNG-1492:
---

This seems to be a duplicate issue of  http://jira.codehaus.org/browse/MNG-1479

Please vote on it instead.

> A more in-depth guide on the elements of the Project descriptor (pom.xml) 
> file.
> ---
>
>  Key: MNG-1492
>  URL: http://jira.codehaus.org/browse/MNG-1492
>  Project: Maven 2
> Type: Improvement
>   Components: documentation - guides
> Reporter: Anuerin Diaz

>
>
> Currently the documentation[1] on the Project descriptor file is sparse. 
> Although most of the basic elements are understandable[2], some of the 
> features remain under utilized (e.g. difference between dependencies and 
> dependencyManagement, plugins and pluginsManagement, etc.).
> A more in-depth explanation or discussion on what are the advantages of each 
> element may be in order. Hopefully the user community can also contribute so 
> that it would be easier to write the guide.
> [1] http://maven.apache.org/maven-model/maven.html
> [2] http://maven.apache.org/guides/introduction/introduction-to-the-pom.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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1492) A more in-depth guide on the elements of the Project descriptor (pom.xml) file.

2005-11-10 Thread Anuerin Diaz (JIRA)
A more in-depth guide on the elements of the Project descriptor (pom.xml) file.
---

 Key: MNG-1492
 URL: http://jira.codehaus.org/browse/MNG-1492
 Project: Maven 2
Type: Improvement
  Components: documentation - guides  
Reporter: Anuerin Diaz


Currently the documentation[1] on the Project descriptor file is sparse. 
Although most of the basic elements are understandable[2], some of the features 
remain under utilized (e.g. difference between dependencies and 
dependencyManagement, plugins and pluginsManagement, etc.).

A more in-depth explanation or discussion on what are the advantages of each 
element may be in order. Hopefully the user community can also contribute so 
that it would be easier to write the guide.

[1] http://maven.apache.org/maven-model/maven.html
[2] http://maven.apache.org/guides/introduction/introduction-to-the-pom.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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1491) Reactor should print out a message if it detects a collision of artifact ids

2005-11-10 Thread Anuerin Diaz (JIRA)
Reactor should print out a message if it detects a collision of artifact ids


 Key: MNG-1491
 URL: http://jira.codehaus.org/browse/MNG-1491
 Project: Maven 2
Type: Wish
  Components: maven-core  
Reporter: Anuerin Diaz
Priority: Trivial


It might be a good idea to have the Reactor print out a warning message if it 
detects similar artifact IDs (copy and paste problem) when scanning for the 
build order at the start of the build.

Currently, there are no messages shown in the screen even if "-X" is used.

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (MNG-1293) Enable multiple assemblies in a pom

2005-11-10 Thread Anuerin Diaz (JIRA)
[ http://jira.codehaus.org/browse/MNG-1293?page=comments#action_50559 ] 

Anuerin Diaz commented on MNG-1293:
---

A similar request would be to be having the ability which artifacts go to which 
directory so that one assembly descriptor would be enough to specify the 
delivery structure if it is required (e.g. separate directories for common 
libraries, for client libraries, etc.). I think this is going to be useful for 
multi-module projects.



> Enable multiple assemblies in a pom
> ---
>
>  Key: MNG-1293
>  URL: http://jira.codehaus.org/browse/MNG-1293
>  Project: Maven 2
> Type: New Feature
>   Components: maven-assembly-plugin
> Versions: 2.0
> Reporter: Jeff Genender

>
>
> Would like the ability to have multiple assemblies in a single pom.  I would 
> like to be able to build a src and binary assembly without the need to create 
> multiple projects.

-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (MNG-1490) antrun fails if ta sk åarameters if of type EnumeratedAttributes

2005-11-10 Thread Anuerin Diaz (JIRA)
antrun fails if task åarameters if of type EnumeratedAttributes
---

 Key: MNG-1490
 URL: http://jira.codehaus.org/browse/MNG-1490
 Project: Maven 2
Type: Bug
  Components: maven-antrun-plugin  
Versions: 2.0
 Environment: Windows XP Professional/JDK 1.4.2_04
Reporter: Anuerin Diaz
 Attachments: sample.zip, testbed-src.zip, testbed.zip

  the ant-run plugin (or the launcher) seems unable to properly convert 
attributes that are of the type EnumeratedAttribute[1]. the execution always 
fail with an error that the attribute being set is not supported by the class.

  i have attached 3 files to serve as a test case for this.

  1. "sample.zip" - contains the project that will serve as the main test case. 
it really is just the plugin tutorial and i just added the followign in the 
pom.xml so my test Task will be called during compile time:

 
   

testbed
tests
1.0


ant
ant
1.5

   
  
 
maven-antrun-plugin

   
  compile
 

   

   


 
 
run
  

 
  
   
 

   2. "testbed.zip" - contains the test Ant Task jar file. the test task has 
one attribute that is derived from EnumeratedAttribute.

   3.  "testbed-src.zip" - contains the source code for the testbed artifact 
(in case somebody is interested).


   i think the problem is just with the launcher since the task runs fairly 
well from normal Ant invocation. i found this problem when i was trying to use 
the  task in the ant-optional package.

   thanks.

 [1] http://ant.apache.org/manual/develop.html#set-magic



-- 
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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]