date:20061011

[ http://jira.codehaus.org/browse/SCM-242?page=comments#action_77229 ] 

Kenney Westerhof commented on SCM-242:
--

:) Thanks anyway!

> NPE on ScmRepositoryException
> -
>
> Key: SCM-242
> URL: http://jira.codehaus.org/browse/SCM-242
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-plugin
>Reporter: Julien HENRY
> Assigned To: Kenney Westerhof
> Attachments: NPE.patch
>
>
> I get a NPE when using Scm plugin with the provider I wrote (Synergy) and the 
> URL is incorrect.
> I think it's because I use the ScmRepositoryException( String msg ) 
> constructor instead of ScmRepositoryException( String msg, List 
> validationMessages ), and the result is 
> e.getValidationMessages().isEmpty()
> raise a NPE.
> Here is stack trace :
> java.lang.NullPointerException
>   at 
> org.apache.maven.scm.plugin.AbstractScmMojo.getScmRepository(AbstractScmMojo.java:258)
>   at 
> org.apache.maven.scm.plugin.CheckoutMojo.checkout(CheckoutMojo.java:94)
>   at 
> org.apache.maven.scm.plugin.BootstrapMojo.execute(BootstrapMojo.java:58)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> ...

-- 
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: (MCLEAN-20) pom packaged (aggregtor) project files shouldn't activate "clean" to delete /target

2006-10-11 Thread David Boden (JIRA)

pom packaged (aggregtor) project files shouldn't activate "clean" to delete 
/target
---

 Key: MCLEAN-20
 URL: http://jira.codehaus.org/browse/MCLEAN-20
 Project: Maven 2.x Clean Plugin
  Issue Type: Improvement
Affects Versions: 2.1
Reporter: David Boden


If you have projects with the following layout:

cds_adapter/pom.xml
cds_adapter/pom-complete.xml - an aggregator
deriv_adapter/pom.xml

Then when you do:
mvn -f pom-complete.xml clean install

what you want is for deriv_adapter's jar to be built and installed followed by 
cds_adapter's jar.

This happens. However, unfortunately the last thing to run is the "clean 
install" task on the pom-complete.xml project. This deletes the 
cds_adapter/target directory. The desired behaviour would be for the aggregator 
pom not to result in the deletion of the /target directory.

Aggregator poms do not install anything into "target" and should not take part 
in the "clean" workflow.

The workaround is to issue the commands separately:
mvn -f pom-complete.xml clean
mvn -f pom-complete.xml install

-- 
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: (MCLEAN-20) pom packaged (aggregtor) project files shouldn't activate "clean" to delete /target

2006-10-11 Thread David Boden (JIRA)

[ http://jira.codehaus.org/browse/MCLEAN-20?page=comments#action_77252 ] 

David Boden commented on MCLEAN-20:
---

This chap is having the same issue:
http://mail-archives.apache.org/mod_mbox/maven-users/200604.mbox/[EMAIL 
PROTECTED]

> pom packaged (aggregtor) project files shouldn't activate "clean" to delete 
> /target
> ---
>
> Key: MCLEAN-20
> URL: http://jira.codehaus.org/browse/MCLEAN-20
> Project: Maven 2.x Clean Plugin
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: David Boden
>
> If you have projects with the following layout:
> cds_adapter/pom.xml
> cds_adapter/pom-complete.xml - an aggregator
> deriv_adapter/pom.xml
> Then when you do:
> mvn -f pom-complete.xml clean install
> what you want is for deriv_adapter's jar to be built and installed followed 
> by cds_adapter's jar.
> This happens. However, unfortunately the last thing to run is the "clean 
> install" task on the pom-complete.xml project. This deletes the 
> cds_adapter/target directory. The desired behaviour would be for the 
> aggregator pom not to result in the deletion of the /target directory.
> Aggregator poms do not install anything into "target" and should not take 
> part in the "clean" workflow.
> The workaround is to issue the commands separately:
> mvn -f pom-complete.xml clean
> mvn -f pom-complete.xml install

-- 
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: (MEAR-39) Scope=provided is not respected

2006-10-11 Thread Jonas Olsson (JIRA)

[ http://jira.codehaus.org/browse/MEAR-39?page=comments#action_77260 ] 

Jonas Olsson commented on MEAR-39:
--

This is something I do not observe. Quite the opposite, I removed an EJB-jar 
duplication (once in root and once in APP-INF\lib) by making the dependency 
"provided" where appropriate. "provided" dependencies of the EAR project itself 
are also excluded.

> Scope=provided is not respected
> ---
>
> Key: MEAR-39
> URL: http://jira.codehaus.org/browse/MEAR-39
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Olle Hallin
>Priority: Critical
>
> The produced ear contains *all* transitive  dependencies, even those with 
> scope=provided (and their dependencies).
> This leads not only to a bloated ear. What is worse is that it also prohibits 
> deployment in JBoss due to class loading conflicts.

-- 
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-2601) mvn -U does NOT update/download the latest SNAPSHOT version

2006-10-11 Thread Jimisola Laursen (JIRA)

mvn -U does NOT update/download the latest SNAPSHOT version
---

Key: MNG-2601
URL: http://jira.codehaus.org/browse/MNG-2601
Project: Maven 2
Issue Type: Bug
Components: Command Line
Affects Versions: 2.0.4
Reporter: Jimisola Laursen
Priority: Critical

I stumbled on this issue (again) with a new snapshot release of Apache's XMLRPC
library (3.1-SNAPSHOT).
For background information see here:
http://www.nabble.com/3.1-SNAPHOT-tf2411158.html

The bug is that mvn -U doesn't download the new 3.1-SNAPSHOT version when there
is one. I had (actually we as in our team) manually have to delete the existing
3.1-SNAPSHOT in my local repository.
The xmlrpc library consists of three modules (common, server and client) this
problems applies to all three but I've make an example using the server modules.

It can be found here:
http://people.apache.org/maven-snapshot-repository/org/apache/xmlrpc/xmlrpc-server/3.1-SNAPSHOT/

The SNAPSHOTs generated does not use uniqueVersion (and filenames are hence not
created with a timestamp). Is that necessary for mvn -U to work?

If that is the case then

1) this needs to be documented better. It is NOT how one expects it to work.
As a user I don't care how the SNAPSHOT was deployed - just that it is there.
2) one should be able to force mvn to RE-download all SNAPSHOT (don't check
for update or anything just download). perhaps mvn -F (force redownload of
snapshots)

--
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-2221) Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times

2006-10-11 Thread Sujan Kapadia (JIRA)

[ http://jira.codehaus.org/browse/MNG-2221?page=comments#action_77271 ] 

Sujan Kapadia commented on MNG-2221:


I still see the following issue under Maven 2.0.4:

In a multi-module project, the parent POM configures the maven-antrun-plugin to 
declare dependencies for the plugin.  In the child POMs, the plugin is being 
executed twice.  The effective POM shows two plugin declarations.  Because of 
MNG-1949, I tried to configure the plugin in the parent POM so all modules 
executing maven-antrun-plugin would have the necessary dependencies.  Can 
anybody comment on this?

Thanks,
Sujan

Parent POM:
  

  
maven-antrun-plugin

  
ant
ant-nodeps
1.6.5
  

  

  

> Multiple Executions of Plugin at Difference Inhertiance levels causes plugin 
> executions to run multiple times
> -
>
> Key: MNG-2221
> URL: http://jira.codehaus.org/browse/MNG-2221
> Project: Maven 2
>  Issue Type: Bug
>  Components: Inheritence and Interpolation
>Affects Versions: 2.0.4
>Reporter: Stephen Duncan Jr
> Assigned To: John Casey
>Priority: Critical
> Fix For: 2.0.5
>
> Attachments: repeat-test.zip
>
>
> Can occur in a variety of ways, but the attached test case shows a parent pom 
> defining an antrun-execution, and then a child specifying another execution 
> with a different id.  Both executions run twice when running from the child.
> I believe this is the same as Kenney Westerhof's comment: 
> http://jira.codehaus.org/browse/MNG-2054#action_62477

-- 
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: (MSUREFIRE-172) Bug into xml report generation

2006-10-11 Thread Christophe Lallement (JIRA)

Bug into xml report generation
--

 Key: MSUREFIRE-172
 URL: http://jira.codehaus.org/browse/MSUREFIRE-172
 Project: Maven 2.x Surefire Plugin
  Issue Type: Bug
  Components: xml generation
 Environment: release 2.0 of maven-surfire-plugin
mvn 2.0.4
Reporter: Christophe Lallement
 Attachments: 
TEST-deai.ft.archi.common.debug.ThreadWarningSystemTest.xml, 
ThreadWarningSystem.java, ThreadWarningSystemTest.java

since 2-3 weeks i have wrong information into my junit test tun (mvn test for 
example)
In fact, the *.txt are right, but the corresponding xml file have wrong entry. 
i means additionnal testcase are present ninto the testcase section.
you can find exmple in attachement (ThreadWarningSystemTest for example). You 
can see that the error number are good (because read into the attribute of the 
first xml tag) but in several TestSuite, we have testcase form other testsuite.

I don't know if this errors comes from maven dependancies update.
What i am sure is: 
1/ a little bit of source modification into my project since this error appears.
2/ no new maven dependancies into my project
3/ i use only ibilio/maven2 as repository.

This errors can'be shown on other projet and other not ...

I have a workaround to solve this issue but with low performance:
 I use the option "fork per test" and the reports is right.
Maybe a way to be investigate can be the temporaly file created by the command 
line: 

Forking command line: java -classpath 
> C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-api\2.0\surefire-api-2.0.jar;C:\HOMEWARE\maven-2_local\o
> rg\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\HOMEWARE\maven-2_local\org\apache\maven\surefire\surefire-booter\2.0\surefire-booter-2.0.jar
>  or
> g.apache.maven.surefire.booter.SurefireBooter C:\temp\surefire40840tmp 
> C:\temp\surefire40841tmp


Any Idea ?
Thx
Christophe


-- 
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: (MNG-2586) Site deployment doesn't work with file://\\shareddir

2006-10-11 Thread Dominique Jean-Prost (JIRA)

 [ http://jira.codehaus.org/browse/MNG-2586?page=all ]

Dominique Jean-Prost closed MNG-2586.
-

Resolution: Won't Fix

Not a bug

> Site deployment doesn't work with file://\\shareddir
> 
>
> Key: MNG-2586
> URL: http://jira.codehaus.org/browse/MNG-2586
> Project: Maven 2
>  Issue Type: Bug
>  Components: Sites & Reporting
>Affects Versions: 2.0.4
> Environment: windows XP
>Reporter: Dominique Jean-Prost
>
> 
>  
>   repo
>   Repo
>   file://\\vsrigel\maven-proxy
>  
>  
>   intranet
>   Intranet
>   file://\\podjp\classes\sitesdev 
>  
> 
> Site deployment doesn't seem to work for me with this url. When I try mvn 
> site:deploy, i get nothing in the url destination, although I get the 
> following output in my dos command :
> [INFO] [site:deploy]
> file://\\podjp\classes\sitesdev/test-common - Session: Opened
> file://\\podjp\classes\sitesdev/test-common - Session: Disconnecting
> file://\\podjp\classes\sitesdev/test-common - Session: Disconnected
> [INFO] 
> 
> [INFO] BUILD SUCCESSFUL
> Please note that if I use file://c:/classes/sitesdev, it does work.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MECLIPSE-78) create eclipse projects which are m2eclipse ready

2006-10-11 Thread Rob Baily (JIRA)

 [ http://jira.codehaus.org/browse/MECLIPSE-78?page=all ]

Rob Baily updated MECLIPSE-78:
--

Attachment: m2eclipse.patch

Ok, I think I may have seen the light! :)  I figured out that the Maven nature 
and builders were NOT actually present.  So the stuff in the patch was 
necessary.  I also see why some people would want to use the -D when the team 
is loosely coupled and why others would want to use the pom configuration if 
they want the team to all work the same.

So I've gone ahead and set the m2eclipse setting up just like the wtpversion 
flag so that it can be used on the command line as -Dm2eclipse or in the pom 
inside the plugin as true.

Basically I did the same things as the previous patch.  I think the 
EclipseWriterConfig class must have been added after the first patch.  I've 
moved some things into there the same way that the wtpversion was done.  I also 
added a message that the m2eclipse support was being added so the user has some 
feeback that they set the flag correctly.

I went ahead and built the patch file with Eclipse.  Let me know if you see any 
problems with it.  I'm willing to help however I can.  Hopefully this can be 
added into the upcoming release.

> create eclipse projects which are m2eclipse ready
> -
>
> Key: MECLIPSE-78
> URL: http://jira.codehaus.org/browse/MECLIPSE-78
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: New Feature
> Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven 
> 2.0.2
>Reporter: Joshua Nichols
> Attachments: m2eclipse.patch, m2eclipse.patch, m2eclipse.patch
>
>
> WIth the recent development of the m2eclipse plugin, I believe it is useful 
> to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from 
> the start. One of the advantages of using m2eclipse is that you don't have to 
> rerun eclipse:eclipse when you update any dependencies.
> A few things are necessary to accomplish this, in terms of changes to 
> .classpath and .project.
> .project needs a new nature and builder added. For the builder:
> 
>   org.maven.ide.eclipse.maven2Builder
>   
> 
> For the nature:
> org.maven.ide.eclipse.maven2Nature
> In the .classpath, we need to add:
>path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>
> In .classpath, you also don't want entries  path="M2_REPO/blah/blah/x.y.z/blah-x.y.z.jar"/>, because they would conflict 
> with m2eclipse setting up the classpath.

-- 
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: (MAVENUPLOAD-1175) new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.7.2

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1175?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1175.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> new version to upload, groupId=org.tango-project artifactId=tango-icon-theme 
> version=0.7.2
> --
>
> Key: MAVENUPLOAD-1175
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1175
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Michael Heuer
> Assigned To: Carlos Sanchez
>
> The Tango Desktop Project exists to create a consistent user experience for 
> free and Open Source software with graphical user interfaces.

-- 
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: (MAVENUPLOAD-1174) Upload

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1174?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1174.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> Upload 
> ---
>
> Key: MAVENUPLOAD-1174
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1174
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Garvin LeClaire
> Assigned To: Carlos Sanchez
>
> Please upload the 1.1.1 version of Findbugs into the repository.  I will need 
> this for updates in progress for the Maven2 findBugs plugin.
> The remaining URLs are
> http://gleclaire.home.insightbb.com/findbugs/findbugsGUI-1.1.1-bundle.jar
> http://gleclaire.home.insightbb.com/findbugs/findbugs-ant-1.1.1-bundle.jar
> http://gleclaire.home.insightbb.com/findbugs/coreplugin-1.1.1-bundle.jar
> http://gleclaire.home.insightbb.com/findbugs/annotations-1.1.1-bundle.jar
> http://gleclaire.home.insightbb.com/findbugs/findbugs-1.1.1-bundle.jar

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MAVENUPLOAD-1172) hibernate-annotations 3.2.0.cr3

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1172?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1172.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> hibernate-annotations 3.2.0.cr3
> ---
>
> Key: MAVENUPLOAD-1172
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1172
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Mark Hobson
> Assigned To: Carlos Sanchez
>
> hibernate-annotations 3.2.0.cr3

-- 
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: (MAVENUPLOAD-1171) hibernate 3.2.0.cr5

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1171?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1171.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> hibernate 3.2.0.cr5
> ---
>
> Key: MAVENUPLOAD-1171
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1171
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Mark Hobson
> Assigned To: Carlos Sanchez
>
> hibernate 3.2.0.cr5

-- 
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: (MAVENUPLOAD-1173) JavaNCSS 28.49 Upload request

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1173?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1173.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> JavaNCSS 28.49 Upload request
> -
>
> Key: MAVENUPLOAD-1173
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1173
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Jean-Laurent de Morlhon
> Assigned To: Carlos Sanchez
> Attachments: ccl-28.49-bundle.jar, javancss-28.49-bundle.jar, 
> jhbasic-28.49-bundle.jar
>
>
> This new JavaNCSS version includes a fix for java 1.5 syntax parsing.
> This issue is related to MJNCSS-4.

-- 
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: (MAVENUPLOAD-1170) Upload Canoo WebTest 1393 (a.k.a. 2.1)

 [ http://jira.codehaus.org/browse/MAVENUPLOAD-1170?page=all ]

Carlos Sanchez closed MAVENUPLOAD-1170.
---

  Assignee: Carlos Sanchez
Resolution: Fixed

> Upload Canoo WebTest 1393 (a.k.a. 2.1)
> --
>
> Key: MAVENUPLOAD-1170
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1170
> Project: maven-upload-requests
>  Issue Type: Wish
>Reporter: Matt Raible
> Assigned To: Carlos Sanchez
>
> Please upload Canoo WebTest build 1393, it's a very useful upgrade that makes 
> UI testing work with the latest version of Script.aculo.us (v1.6.4).

-- 
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-1169) please upload this bundle to ibiblio

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1169?page=comments#action_77286 ] 

Carlos Sanchez commented on MAVENUPLOAD-1169:
-

First, paste the url of the bundle, that one is a web page
Second, hendrey.orm is not valid as groupId, it has to be a domain you own or 
control, like shadesdb.sf.net if you are in that project

> please upload this bundle to ibiblio
> 
>
> Key: MAVENUPLOAD-1169
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1169
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: geoff hendrey
>
> shades database framework

-- 
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-1161) Maven XML Validation Plugin upload request

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1161?page=comments#action_77287 ] 

Carlos Sanchez commented on MAVENUPLOAD-1161:
-

The groupId is not valid unless you control maven.plugins.java.net

It should be something like 
net.java.dev.maven-xmlvalidate-plugin

> Maven XML Validation Plugin upload request
> --
>
> Key: MAVENUPLOAD-1161
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1161
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Peter Runge
>
> http://maven-xmlvalidate-plugin.dev.java.net/files/documents/5561/41489/xmlvalidate-parent-1.0-bundle.jar
> http://maven-xmlvalidate-plugin.dev.java.net/files/documents/5561/41490/maven-xmlvalidate-plugin-1.0-bundle.jar
> http://maven-xmlvalidate-plugin.dev.java.net/files/documents/5561/41491/xmlvalidate-archetype-1.0-bundle.jar
> http://maven-xmlvalidate-plugin.dev.java.net/files/documents/5561/41492/j2ee-1.4-bundle.jar
> http://maven-xmlvalidate-plugin.dev.java.net/files/documents/5561/41493/struts-1.3.5-bundle.jar
> http://maven-xmlvalidate-plugin.dev.java.net
> http://maven-xmlvalidate-plugin.dev.java.net/nonav/site/team-list.html
> XML Validation Plugin for Maven 2.  Also in the bundles is an archetype for 
> creating schema JARs and two schema JARs for validating Struts and J2EE 1.4 
> files.  I placed the first URL into the 'Bundle URL' field although there are 
> five to upload.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MAVENUPLOAD-1143) Upload Echo2 2.1.0.beta5 (corrected groupId)

[ 
http://jira.codehaus.org/browse/MAVENUPLOAD-1143?page=comments#action_77288 ] 

Carlos Sanchez commented on MAVENUPLOAD-1143:
-

webcontainer bundle has wrong files

> Upload Echo2 2.1.0.beta5 (corrected groupId)
> 
>
> Key: MAVENUPLOAD-1143
> URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1143
> Project: maven-upload-requests
>  Issue Type: Task
>Reporter: Edson Yanaga
> Attachments: echo2-app-2.1.0.beta5-bundle.jar, 
> echo2-webcontainer-2.1.0.beta5-bundle.jar, 
> echo2-webrender-2.1.0.beta5-bundle.jar
>
>
> http://www.insula.com.br/maven-upload/echo2-app-2.1.0.beta5-bundle.jar
> http://www.insula.com.br/maven-upload/echo2-webcontainer-2.1.0.beta5-bundle.jar
> http://www.insula.com.br/maven-upload/echo2-webrender-2.1.0.beta5-bundle.jar
> http://www.nextapp.com/platform/echo2/echo/
> Echo2 is a framework for developing rich client applications in the browser.
> I'm not a developer, and the packages are named nextapp.* (don't know if it 
> will be a problem...)
> I've modified the groupId to meet com.nextapp (I knew it the first time, but 
> since the packages in echo2 are named nextapp.*, I chose to keep it).

-- 
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: (MECLIPSE-164) class folders not handled

[ http://jira.codehaus.org/browse/MECLIPSE-164?page=comments#action_77297 ] 

Kenney Westerhof commented on MECLIPSE-164:
---

Hm, I've checked to see if there's another way to fix this, but eclipse is very 
limited. It could probably be done by defining a user library, but that's at 
the workspace
level.

The patch looks ok, but a few suggestions:

1) the code is not formatted properly - please take care of that. Also don't 
add 'Modif FL' statements.

2) I'd rather see the getClassFoldername moved to IdeUtils as 'fixSepatator', 
moving the code from 'toRelativeAndFixSeparator'

3) could you move the check if it is a class folder to a new method in 
IdeDependency? So remove the loop in the setDeps, move the check to a separate 
method.

4) Finally, could you re-use the loop that's now done for isPde()? That already 
loops all dependencies.. You could add a switch there to see if it's 
PDE&provided || linkedFolder. 

Don't get me wrong, your solution is perfect, but this might reduce the 
(already high) number of utility methods and if/else stuff a bit..

If you don't want to refactor, just fix the formatting and it'll be done later 
on.

Thanks!

> class folders not handled
> -
>
> Key: MECLIPSE-164
> URL: http://jira.codehaus.org/browse/MECLIPSE-164
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>  Components: dependency resolution
>Affects Versions: 2.2
>Reporter: Francois Loison
> Attachments: patch.classfolder.txt
>
>
> I defined in POM a class folder:
> 
>   com.ptc
>   wt.codebase
>   1.0
>   system
>   c:/dev/java/maven/wdc.ptc/codebase
> 
> This allows to add c:/dev/java/maven/wdc.ptc/codebase to compile classpath.
> Generated Eclipse .classpath file contains following entry:
>   
> This entry is failing: Eclipse 3.2 doesn't accept external project folders 
> for class folders.
> To resolve this, I create manually a linked folder in .project and defines 
> class folder to point on linked folder.
> This may be an hint for resolution.

-- 
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-2602) maven-csharp-source-plugin:process-classes messes up outputDirectory and thereby indirectly messes up release plugin

2006-10-11 Thread James Carpenter (JIRA)

maven-csharp-source-plugin:process-classes messes up outputDirectory and 
thereby indirectly messes up release plugin


 Key: MNG-2602
 URL: http://jira.codehaus.org/browse/MNG-2602
 Project: Maven 2
  Issue Type: Bug
  Components: Sandbox
 Environment: Windows XP
Reporter: James Carpenter
Priority: Critical


Within the csharp plugins 
org.apache.maven.plugins:maven-csharp-source-plugin:process-classes is 
registered at the process-classes phase.  Within this plugin the execute method 
resets the output directory to be that of the actual artifact 
(target/dotnet-assembly/somelib.dll) rather than the directory which it was set 
to (target/dotnet-assembly).

The short javadoc within 
org.apache.maven.plugin.csharp.source.ProcessClassesMojo says:
---
This Mojo adds the result of the compile to the classpath elements
This is required by the NUnitMojo.


As it turns out this has very negative side affects.  If one tries to run 
multiple goals at once (mvn deploy site-deploy), the first goal is very likely 
to mess up the effective pom for the following goal.  This is what happens to 
the release plugin.  During release:perform the release plugin uses the plexus 
command line tools to run "mvn --no-plugin-updates --variousOtherFlags deploy 
site-deploy" within target/checkout.  As you might imagine this really messes 
things up, such that the site-deploy fails as it tries to find 
target/checkout/target/dotnet-assembly/somelib.dll/somelib.dll.

In summary a better way to keep the NUnit plugin happy must be found, as the 
current solution is very problematic.


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

Henri Yandell commented on MRM-204:
---

Managed Repositories (okay, tis obvious but would need doccing).
Synchronized Repositories.
Validated user.
System administrator (access to what?)
Why an option for Indexed?


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

Henri Yandell commented on MRM-204:
---

Simple doc on what each subproject of Archiva does.

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

Henri Yandell commented on MRM-204:
---

archiva-applet - The progress bar on the checksum checking page.
archiva-configuration - A facade on top of the Plexus configuration XML.
archiva-converter - 
archiva-core - central code, business objects, modello etc.
archiva-discoverer - monitors the managed repositories and kicks off the 
indexing.
archiva-indexer - the lucene indexing.
archiva-plexus-application - archiva can run on plexus as well as as a war. 
This creates a plexus app.
archiva-plexus-runtime  - archiva can run on plexus as well as as a war. This 
runs lots of apps.
archiva-proxy - proxy repositories?
archiva-reports-standard - a couple of reports are implemented. Not very 
pluginable yet.
archiva-repository-layer - 
archiva-security - webapp security
archiva-utils - some handy archiva specific utils 
archiva-webapp - creates a war file
design - contains a mock-up currently
maven-meeper - rsync scripts to sync repositories. Also converts m1 
repositories to m2 repositories.

> 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] Created: (MPLUGIN-24) Generated Goal documentation displays incorrect type for arrays

2006-10-11 Thread Micah Whitacre (JIRA)

Generated Goal documentation displays incorrect type for arrays
---

 Key: MPLUGIN-24
 URL: http://jira.codehaus.org/browse/MPLUGIN-24
 Project: Maven 2.x Plugin Plugin
  Issue Type: Bug
Reporter: Micah Whitacre
Priority: Minor


The site document generated to display specific goal information (site\Project 
Reports\Plugin documentation\) does not correctly display the 
type for a parameter which is an array.  

An example of this would be if a goal has a parameter defined like the example 
below:

/**
* @parameter expression="${vmArgs}"
*/
private String[] vmArgs;

the generated site displays the parameter as only having a type of "String".  
This is misleading since it should be type "String[]".

-- 
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-2602) maven-csharp-source-plugin:process-classes messes up outputDirectory and thereby indirectly messes up release plugin

2006-10-11 Thread James Carpenter (JIRA)

[ http://jira.codehaus.org/browse/MNG-2602?page=comments#action_77335 ] 

James Carpenter commented on MNG-2602:
--

This bug is most annoying if you have a report registered which requires the 
outputDirectory not to be messed up.  For example my newer NDOC plugin gets mad 
because of this bug.  In projects which don't use the ndoc report plugin, the 
problem goes unnoticed.  This is not to say it doesn't always exist, it just 
doesn't always show its ugly head.

> maven-csharp-source-plugin:process-classes messes up outputDirectory and 
> thereby indirectly messes up release plugin
> 
>
> Key: MNG-2602
> URL: http://jira.codehaus.org/browse/MNG-2602
> Project: Maven 2
>  Issue Type: Bug
>  Components: Sandbox
> Environment: Windows XP
>Reporter: James Carpenter
>Priority: Critical
>
> Within the csharp plugins 
> org.apache.maven.plugins:maven-csharp-source-plugin:process-classes is 
> registered at the process-classes phase.  Within this plugin the execute 
> method resets the output directory to be that of the actual artifact 
> (target/dotnet-assembly/somelib.dll) rather than the directory which it was 
> set to (target/dotnet-assembly).
> The short javadoc within 
> org.apache.maven.plugin.csharp.source.ProcessClassesMojo says:
> ---
> This Mojo adds the result of the compile to the classpath elements
> This is required by the NUnitMojo.
> 
> As it turns out this has very negative side affects.  If one tries to run 
> multiple goals at once (mvn deploy site-deploy), the first goal is very 
> likely to mess up the effective pom for the following goal.  This is what 
> happens to the release plugin.  During release:perform the release plugin 
> uses the plexus command line tools to run "mvn --no-plugin-updates 
> --variousOtherFlags deploy site-deploy" within target/checkout.  As you might 
> imagine this really messes things up, such that the site-deploy fails as it 
> tries to find target/checkout/target/dotnet-assembly/somelib.dll/somelib.dll.
> In summary a better way to keep the NUnit plugin happy must be found, as the 
> current solution is very problematic.

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

Henri Yandell commented on MRM-204:
---

Identifier - internal ID. Could be generated by Archiva probably instead of 
being a user thing. Check to see if it's used in the urls.

Proxy - Haivng a single local address (maven-proxy style) which lets you wrap 
many ones into a single one. Check you can proxy a local file system.

Synchronized - wget ibiblio etc. 

Managed - browseable? indexed? need to figure out.

> 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: (MJAVADOC-87) doc-files ignored if they reside in the resources directory

2006-10-11 Thread Matthew Beermann (JIRA)

[ http://jira.codehaus.org/browse/MJAVADOC-87?page=comments#action_77344 ] 

Matthew Beermann commented on MJAVADOC-87:
--

I wish I'd remembered to test this before you released the Javadoc plugin, 
because it doesn't seem to actually work. Create a src/main/javadoc folder in 
your project, and add some files to it. They don't appear anywhere in the 
javadoc:javadoc output...

> doc-files ignored if they reside in the resources directory
> ---
>
> Key: MJAVADOC-87
> URL: http://jira.codehaus.org/browse/MJAVADOC-87
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Matthew Beermann
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
>
> It looks like MJAVADOC-76 was closed prematurely, or maybe it just had a bad 
> summary. The bug is this: if you have a "doc-files" folder in the 
> "src/main/resources" branch of your project, its contents will be omitted 
> from the Javadoc output. However, if you move the same folder over to 
> "src/main/java", it will be included in the output. This bug is present in 
> the released (2.0) version of the plugin.
> The file "package.html", by comparison, will be included in the Javadoc 
> output no matter where it is. This is the expected behavior, AFAICT. More 
> information about the "doc-files" directory can be found here: 
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#unprocessed

-- 
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: (MRM-210) Error while indexing m1 plugin

2006-10-11 Thread Arnaud Heritier (JIRA)

Error while indexing m1 plugin
--

 Key: MRM-210
 URL: http://jira.codehaus.org/browse/MRM-210
 Project: Archiva
  Issue Type: Bug
  Components: indexing
 Environment: last from trunk
Reporter: Arnaud Heritier


trying to index my local m1 repository I encounter the following stacktrace :

{code}
java.lang.IllegalStateException: Couldn't find artifact 
E:\Data\maven-1\repository\cargo\plugins\cargo-maven-plugin-0.6.plugin

org.apache.maven.archiva.reporting.LocationArtifactReportProcessor.processArtifact(LocationArtifactReportProcessor.java:143)

org.apache.maven.archiva.reporting.AbstractReportGroup.processArtifact(AbstractReportGroup.java:53)

org.apache.maven.archiva.reporting.DefaultReportExecutor.runArtifactReports(DefaultReportExecutor.java:126)

org.apache.maven.archiva.scheduler.task.IndexerTask.execute(IndexerTask.java:201)

org.apache.maven.archiva.scheduler.task.IndexerTask.execute(IndexerTask.java:122)

org.apache.maven.archiva.scheduler.DefaultRepositoryTaskScheduler.runIndexer(DefaultRepositoryTaskScheduler.java:175)

org.apache.maven.archiva.web.action.admin.RunRepositoryTaskAction.runIndexer(RunRepositoryTaskAction.java:45)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)

com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364)

com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)

org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:67)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:141)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

org.codehaus.plexus.security.ui.web.interceptor.AutoLoginInterceptor.intercept(AutoLoginInterceptor.java:89)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

org.codehaus.plexus.security.ui.web.interceptor.ForceAdminUserInterceptor.intercept(ForceAdminUserInterceptor.java:59)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

org.codehaus.plexus.security.ui.web.interceptor.EnvironmentCheckInterceptor.intercept(EnvironmentCheckInterceptor.java:123)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168)

com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)

com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.webwork.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:147)

com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)

com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)

[jira] Closed: (MECLIPSE-161) need flag to specify eclipse project name

 [ http://jira.codehaus.org/browse/MECLIPSE-161?page=all ]

Kenney Westerhof closed MECLIPSE-161.
-

Resolution: Duplicate

Duplicate of MECLIPSE-119

> need flag to specify eclipse project name
> -
>
> Key: MECLIPSE-161
> URL: http://jira.codehaus.org/browse/MECLIPSE-161
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Brian Fox
>Priority: Minor
>
> We have multiple branches of our projects and the name is the same. We need 
> the ability to define a new name so that both can coexist in eclipse at the 
> same time. (you can't choose the name when importing). I was thinking of just 
> a simple -Declipse.name= would be sufficient. 

-- 
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: (MECLIPSE-79) exclude dependencies from the Classpath Container

[ http://jira.codehaus.org/browse/MECLIPSE-79?page=comments#action_77349 ] 

Kenney Westerhof commented on MECLIPSE-79:
--

Those dependencies should be declared with scope=provided; those aren't 
currently imported in the eclipse classpath.

However, there's another issue that requests provided scoped deps to be added 
to the classpath since they're necessary for
compilation.

I don't think that removing the javax.servlet dependency will work here - if 
you have servlets defined in the project they won't compile
(not unless that tomcat plugin defines a custom library that contains it..)

Right?

> exclude dependencies from the Classpath Container
> -
>
> Key: MECLIPSE-79
> URL: http://jira.codehaus.org/browse/MECLIPSE-79
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
> Environment: Windows, Eclipse 3.1.2
>Reporter: Martin Goldhahn
> Attachments: MECLIPSE-79.patch
>
>
> There are some dependencies that need to be in the POM in order to compile 
> the project (e.g. javax.servlet). When I use Sysdeo's Tomcat plugin, I get an 
> error because the servlet classes from the POM are included in the classpath 
> via the classpath container.

-- 
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: (MJAVADOC-87) doc-files ignored if they reside in the resources directory

2006-10-11 Thread Vincent Siveton (JIRA)

 [ http://jira.codehaus.org/browse/MJAVADOC-87?page=all ]

Vincent Siveton updated MJAVADOC-87:


Attachment: my-app.zip

Seems to work. 
Check the sample project.

> doc-files ignored if they reside in the resources directory
> ---
>
> Key: MJAVADOC-87
> URL: http://jira.codehaus.org/browse/MJAVADOC-87
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Matthew Beermann
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
> Attachments: my-app.zip
>
>
> It looks like MJAVADOC-76 was closed prematurely, or maybe it just had a bad 
> summary. The bug is this: if you have a "doc-files" folder in the 
> "src/main/resources" branch of your project, its contents will be omitted 
> from the Javadoc output. However, if you move the same folder over to 
> "src/main/java", it will be included in the output. This bug is present in 
> the released (2.0) version of the plugin.
> The file "package.html", by comparison, will be included in the Javadoc 
> output no matter where it is. This is the expected behavior, AFAICT. More 
> information about the "doc-files" directory can be found here: 
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#unprocessed

-- 
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: (MECLIPSE-113) refactored code

 [ http://jira.codehaus.org/browse/MECLIPSE-113?page=all ]

Kenney Westerhof closed MECLIPSE-113.
-

Resolution: Cannot Reproduce

> refactored code
> ---
>
> Key: MECLIPSE-113
> URL: http://jira.codehaus.org/browse/MECLIPSE-113
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
> Environment: Windows XP SP2 - Java 1.5.0.6 - Eclipse 3.2M7
>Reporter: Francesco Tinti
>Priority: Minor
> Attachments: refactored-code.patch
>
>
> It's a bit refactored code of the original plugin (SVN 405286). 
> Changes: 
> - EclipseXMLWriter to incapsulate use of 
> org.codehaus.plexus.util.xml.XMLWriter;
> - classes and interfaces for Component and Facet writers;
> - "resolvers" classes and factory utils for Java, J2EE, EJB, and Servlet 
> versions;
> Actually only testMinConfiguration fails, all others seems to work correctly.
> It's a few hours work so dependencies are written in Eclipse .classpath not 
> in order because code I wrote uses hashtables
> If it could be interesting, please let me know

-- 
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: (MECLIPSE-152) Write .classpath with ordered dependencies [incl. Patch]

[ http://jira.codehaus.org/browse/MECLIPSE-152?page=comments#action_77352 ] 

Kenney Westerhof commented on MECLIPSE-152:
---

You're right. I created a separate issue (MECLIPSE-170) to address the 
erroneous classpath issue.

As for the sorting on names, that's a really good idea since I'm always 
searching huge lists of dependencies to see if a jar is in there.

> Write .classpath with ordered dependencies [incl. Patch]
> 
>
> Key: MECLIPSE-152
> URL: http://jira.codehaus.org/browse/MECLIPSE-152
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Improvement
>Affects Versions: 2.2
> Environment: Windowz XP, eclipse 3.2
>Reporter: Holger Hoffstätte
> Assigned To: Kenney Westerhof
> Attachments: orderDependencies.patch, orderDependencies.patch
>
>
> Related to my comment in MNG-1412 - I decided to take a quick stab at the 
> eclipse plugin and voilá! Ordered dependencies in the written .classpath. 
> This is only a prototype (my first attempt at maven development) and could 
> serve as basis for other orderings like groupId, transitive nearness etc.
> Initially I wanted to make IdeDependency comparable (similar to MECLIPSE-150 
> which added proper equals) but having multiple Comparators seemed better for 
> extensibility.
> It worked right away, does exactly what I want (ordering by artifactId) and 
> has minimal impact. I am not familiar with the maven codebase so I hope this 
> is the right place to do the actual ordering before writing; obviously it 
> should observe a property like -DorderDependencies=artifactId or something 
> similar. The patch is against svn r425750 (2006-08-30). Currently no testcase 
> but if someone tells me how to add/read an orderDependencies property I might 
> add one.
> Comments welcome.

-- 
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: (MECLIPSE-170) Exports on classpath entries destroy the classpath

Exports on classpath entries destroy the classpath
--

 Key: MECLIPSE-170
 URL: http://jira.codehaus.org/browse/MECLIPSE-170
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Kenney Westerhof
 Assigned To: Kenney Westerhof
Priority: Critical
 Fix For: 2.3


When all dependencies of projects are marked as 'exported' in the .classpath 
file, this creates chaos in the classpath.

An example:

continuum-release depends on:

* maven-project 2.0.4
* maven-release-plugin, which depends on maven-project 2.0

Due to an API change (ProjectSorter added another exception in 2.0.4), I get an 
error in eclipse,
because the code catches the exception defined in 2.0.4 but eclipse sees the 
implementation
from 2.0 which doesn't throw that.


Two solutions:

* sort projects by transitive dependencies, so that the correct version is 
resolved. However, eclipse doesn't honor the order - project dependencies seem 
to come before library dependencies, no matter what the order is in the 
BuildPath->Order And Export tab. Ordering is also impossible, because two 
projects could be considered to be listed before eachoter:

MAIN depends on A and B.
A depends on C 1.0 and D 1.1
B depends on C 1.1 and D 1.0.
MAIN depends on C 1.0 and D 1.0.

No way to order this properly, A needs to come before B because of C, and B 
needs to come before A because of D.

Anyway, this option doesn't work.

* Simplest solution: do NOT export any dependencies, and list all 
transitive dependencies explicitly. As the plugin currently already
  lists all transitive dependencies as project dependencies in eclipse, all 
that needs to be done is remove the 'exported="true"' flag
 from the .classpath entries.



-- 
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: (MJAVADOC-87) doc-files ignored if they reside in the resources directory

2006-10-11 Thread Matthew Beermann (JIRA)

[ http://jira.codehaus.org/browse/MJAVADOC-87?page=comments#action_77353 ] 

Matthew Beermann commented on MJAVADOC-87:
--

How does that sample project show that it worked? If it did, 
target/site/apidocs/com/mycompany/app should contain a file called just 
"package.html", but it doesn't.

> doc-files ignored if they reside in the resources directory
> ---
>
> Key: MJAVADOC-87
> URL: http://jira.codehaus.org/browse/MJAVADOC-87
> Project: Maven 2.x Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Matthew Beermann
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
> Attachments: my-app.zip
>
>
> It looks like MJAVADOC-76 was closed prematurely, or maybe it just had a bad 
> summary. The bug is this: if you have a "doc-files" folder in the 
> "src/main/resources" branch of your project, its contents will be omitted 
> from the Javadoc output. However, if you move the same folder over to 
> "src/main/java", it will be included in the output. This bug is present in 
> the released (2.0) version of the plugin.
> The file "package.html", by comparison, will be included in the Javadoc 
> output no matter where it is. This is the expected behavior, AFAICT. More 
> information about the "doc-files" directory can be found here: 
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#unprocessed

-- 
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: (MECLIPSE-170) Exports on classpath entries destroy the classpath

 [ http://jira.codehaus.org/browse/MECLIPSE-170?page=all ]

Kenney Westerhof closed MECLIPSE-170.
-

Resolution: Fixed

Fixed in svn revision 463011

> Exports on classpath entries destroy the classpath
> --
>
> Key: MECLIPSE-170
> URL: http://jira.codehaus.org/browse/MECLIPSE-170
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Kenney Westerhof
> Assigned To: Kenney Westerhof
>Priority: Critical
> Fix For: 2.3
>
>
> When all dependencies of projects are marked as 'exported' in the .classpath 
> file, this creates chaos in the classpath.
> An example:
> continuum-release depends on:
> * maven-project 2.0.4
> * maven-release-plugin, which depends on maven-project 2.0
> Due to an API change (ProjectSorter added another exception in 2.0.4), I get 
> an error in eclipse,
> because the code catches the exception defined in 2.0.4 but eclipse sees the 
> implementation
> from 2.0 which doesn't throw that.
> Two solutions:
> * sort projects by transitive dependencies, so that the correct version 
> is resolved. However, eclipse doesn't honor the order - project dependencies 
> seem to come before library dependencies, no matter what the order is in the 
> BuildPath->Order And Export tab. Ordering is also impossible, because two 
> projects could be considered to be listed before eachoter:
> MAIN depends on A and B.
> A depends on C 1.0 and D 1.1
> B depends on C 1.1 and D 1.0.
> MAIN depends on C 1.0 and D 1.0.
> No way to order this properly, A needs to come before B because of C, and B 
> needs to come before A because of D.
> Anyway, this option doesn't work.
> * Simplest solution: do NOT export any dependencies, and list all 
> transitive dependencies explicitly. As the plugin currently already
>   lists all transitive dependencies as project dependencies in eclipse, 
> all that needs to be done is remove the 'exported="true"' flag
>  from the .classpath entries.

-- 
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: (MECLIPSE-100) should have option to download and attach javadocs regardless of source archive status