[jira] Updated: (MSITE-179) Maven-site-plugin ignores the encoding specified in XML file (e.g. site.xml or xdoc/x.xml).
[ http://jira.codehaus.org/browse/MSITE-179?page=all ] Bernhard Wellhöfer updated MSITE-179: - Attachment: MSITE179DemoProject.zip Please find attached a demo project. The site documentation contains two completly legal and correct encoded XML documents. But when the site documentation is build only one file is converted correctly to a HTML file. > Maven-site-plugin ignores the encoding specified in XML file (e.g. site.xml > or xdoc/x.xml). > --- > > Key: MSITE-179 > URL: http://jira.codehaus.org/browse/MSITE-179 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Bernhard Wellhöfer > Attachments: MSITE179DemoProject.zip > > > Each XML document defines the used encoding. The maven-site-plugin ignores > this encoding and always uses the value of the inputEncoding configuration > value. The inputEncoding value should only be used for the non XML site files. -- 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: (MRM-136) improve performance of the browse interface
[ http://jira.codehaus.org/browse/MRM-136?page=all ] Brett Porter closed MRM-136. Assignee: Brett Porter Resolution: Fixed > improve performance of the browse interface > --- > > Key: MRM-136 > URL: http://jira.codehaus.org/browse/MRM-136 > Project: Archiva > Issue Type: Improvement > Components: web application, browser >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > currently the browser reads the entire index to be able to present some > pages. It should be able to just read the terms, and some of this information > should be cached -- 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-40) associate artifacts with their pom and checksums
[ http://jira.codehaus.org/browse/MRM-40?page=comments#action_74015 ] Brett Porter commented on MRM-40: - while I'm now happy not to do this, I need to do a final review of the index design since it changed recently to ensure that separated discovery of poms and artifacts (esp. if they have a classifier) works correctly. > associate artifacts with their pom and checksums > > > Key: MRM-40 > URL: http://jira.codehaus.org/browse/MRM-40 > Project: Archiva > Issue Type: Task > Components: discovery >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1107) upload jguard v1.00-beta-1 jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1107?page=comments#action_74016 ] charles gay commented on MAVENUPLOAD-1107: -- Hi carlos, must i create the bundle manually?should i use 'mvn jar' to do it? => if i try 'mvn repository bunle:create,' maven says to me " Packaging cannot be POM when creating an upload bundle". sorry to annoy you with this request, but i don't see any guidelines in the "Guide to uploading artifacts to Ibiblio" about multi-modules project. cheers, Charles GAY. > upload jguard v1.00-beta-1 jars > --- > > Key: MAVENUPLOAD-1107 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1107 > Project: maven-upload-requests > Issue Type: Task >Reporter: charles gay > > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-core-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-ext-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-jee-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-struts-example-1.00-beta-1-bundle.jar > http://jguard.sourceforge.net/v1.00/1.00-beta-1/jguard-swing-example-1.00-beta-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: (CONTINUUM-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Carlos Sanchez closed CONTINUUM-800. Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 1.1 > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-800-continuum-acegi-branch.patch, > CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-model-testing.patch, > CONTINUUM-800-maven-user-model-update-2.patch, > CONTINUUM-800-maven-user-webapp-update-2.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-842) Maven-user improvements
Maven-user improvements --- Key: CONTINUUM-842 URL: http://jira.codehaus.org/browse/CONTINUUM-842 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Henry S. Isidro -- 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: (CONTINUUM-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=all ] Carlos Sanchez updated CONTINUUM-842: - Description: - user list page shows user.usernameuser.email - when adding a user, the roles list shouldn't show up, only on editing Fix Version/s: 1.1 Component/s: Web interface > Maven-user improvements > --- > > Key: CONTINUUM-842 > URL: http://jira.codehaus.org/browse/CONTINUUM-842 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > - user list page shows user.username user.email > - when adding a user, the roles list shouldn't show up, only on editing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74017 ] Carlos Sanchez commented on CONTINUUM-842: -- links in left menu are relative, which means that while doing user management they point to a wrong place > Maven-user improvements > --- > > Key: CONTINUUM-842 > URL: http://jira.codehaus.org/browse/CONTINUUM-842 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > - user list page shows user.username user.email > - when adding a user, the roles list shouldn't show up, only on editing -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_74018 ] Sharma, Jaikumar commented on SUREFIRE-31: -- As you know, testing is an unavoidable part of any software projects to really harness the quality of software products, since JUnit 4.x is out and its being a de facto standard in testing, I think surefire plugin issues should be solved as soon as possible to really support JUnit 4.x using Maven 2. Thanks. > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_74020 ] Max Bowsher commented on MJAR-28: - I do not agree that this issue should be closed. It is true that outputFileNameMapping provides a workaround, but it is only a workaround, not a true fix. I am investigating how to make the jar plugin add the actual timestamped name to the classpath. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74021 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-842: --- The password fields in the General Configuration do not hide the entered passwords. > Maven-user improvements > --- > > Key: CONTINUUM-842 > URL: http://jira.codehaus.org/browse/CONTINUUM-842 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > - user list page shows user.username user.email > - when adding a user, the roles list shouldn't show up, only on editing -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74022 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-842: --- The password fields when adding new users do not hide the entered passwords too. > Maven-user improvements > --- > > Key: CONTINUUM-842 > URL: http://jira.codehaus.org/browse/CONTINUUM-842 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > - user list page shows user.username user.email > - when adding a user, the roles list shouldn't show up, only on editing -- 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: (MCLOVER-47) review plugin documentation
[ http://jira.codehaus.org/browse/MCLOVER-47?page=comments#action_74023 ] Vincent Massol commented on MCLOVER-47: --- Hi Franz. Thanks for your patch. Good work! I've started to apply it. The only part that seems strange is the examples section. What you have moved to there from my howto guide are NOT examples but usage documentation! Examples are scattered throughout the usage section and I don't understand why there's a need to have a specific examples section. I know docck seems to require it but I'd like to better understand the need for this section before applying anything. Also, please add my name to all documents containing text that you have reused from my howto guide :-) And make sure to change their titles as "Simple" doesn't seem right ;-) Let me know what you think. Thanks -Vincent > review plugin documentation > --- > > Key: MCLOVER-47 > URL: http://jira.codehaus.org/browse/MCLOVER-47 > Project: Maven 2.x Clover Plugin > Issue Type: Task >Affects Versions: 2.2 >Reporter: John Tolentino > Assigned To: Vincent Massol > Fix For: 2.3 > > Attachments: MCLOVER-47-maven-clover-plugin.patch > > > http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-842) Maven-user improvements
[ http://jira.codehaus.org/browse/CONTINUUM-842?page=comments#action_74024 ] Henry S. Isidro commented on CONTINUUM-842: --- - user list page shows user.username user.email It seems that extremcomponents cannot get the localization info correctly. In fact, the MavenUsers.properties file which contains the values for user.username and user.email is not in continuum-webapp. I think that when maven-user-webapp was overlayed, MavenUsers.properties was not included. > Maven-user improvements > --- > > Key: CONTINUUM-842 > URL: http://jira.codehaus.org/browse/CONTINUUM-842 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Henry S. Isidro > Fix For: 1.1 > > > - user list page shows user.username user.email > - when adding a user, the roles list shouldn't show up, only on editing -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_74025 ] Baerrach bonDierne commented on MJAR-28: The patch I provided does just that, for SNAPSHOTS it uses the timestamped version instead of -SNAPSHOT. > Using the jar plugin with addClasspath and snapshots can create manifest > classpath with incorrect jar versions > -- > > Key: MJAR-28 > URL: http://jira.codehaus.org/browse/MJAR-28 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark J. Titorenko > Attachments: MJAR-28-patch.txt > > > When the POM contains dependencies to snapshot versions of jars, and snapshot > versions of those jars are downloaded from a remote repository, the name of > the jar contained in the classpath added to the manifest, of the form > artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar > downloaded, which contains version information of the form > artifactID-X.X-MMDD.HHmmss-V.jar. > This does not affect snapshot versions which have been directly installed > into a local repository and have no uploaded version within the remote > repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar > form. -- 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
Maven+Checkstyle - Configuration file location
We use maven+checkstyle on a multi-project. We have defined our checks (mycheckstyle.xml) for one of the component. The xml file is stored right at the root of the component (next to the src and target folders) in the top pom file we have: org.apache.maven.plugins maven-checkstyle-plugin mycheckstyle.xml So we have a structure like this topProject --- pom.xml --- subComponent1 --- --- src --- --- target --- --- pom.xml --- --- mycheckstyle.xml --- --- ... --- subComponent2 --- --- src --- --- target --- --- pom.xml --- --- ... --- --- subsubComponent2.1 --- --- --- src --- --- --- target --- --- --- pom.xml --- --- --- ... This works fine. But now, we would like to use the same configuration file for ALL our component. So, we would like to have our (single) mycheckstyle.xml file stored only once, right under the topProject, next to the top pom.xml file. How can we define that in the pom file. I tried using relative path (../mycheckstyle.xml), full url (file:../mycheckstyle.xml), using maven variables ($project.dir/mycheckstyle.xml) but without success, always with one or another error message from maven such as Unable to find location '../mycheckstyle.xml' as URL, File or Resource. Is there any way to combine maven's knowledge of the project/components tree so that each individual component knwos the top level and use it to locate the mycheckstyle.xml. Even better: is there a way to support component with different level in the tree (as subComponent2 and subComponent2.1 in the example above) Thanks, Olivier
[jira] Closed: (MJAVADOC-81) Additional doclets do not run.
[ http://jira.codehaus.org/browse/MJAVADOC-81?page=all ] Vincent Siveton closed MJAVADOC-81. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Applied with destDir instead of outputName Thanks! > Additional doclets do not run. > -- > > Key: MJAVADOC-81 > URL: http://jira.codehaus.org/browse/MJAVADOC-81 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Shinobu Kawai > Assigned To: Vincent Siveton >Priority: Critical > Fix For: 2.1 > > Attachments: MJAVADOC-81, pom.xml > > > Although it is stated in the docs [1] that you can generate alternate doclet > in addition to the project javadocs, only the first reportSet is run. > This is due to the fact that JavadocReport#getOutputName(...) returns a fixed > value, "apidocs/index". This should be configurable per reportSet. > [1] http://maven.apache.org/plugins/maven-javadoc-plugin/configuration.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-84) destDir not used when generating a site
[ http://jira.codehaus.org/browse/MJAVADOC-84?page=all ]
Vincent Siveton closed MJAVADOC-84.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.1
Fixed due MJAVADOC-81.
For more information, refer to alternate-doclet page.
> destDir not used when generating a site
> ---
>
> Key: MJAVADOC-84
> URL: http://jira.codehaus.org/browse/MJAVADOC-84
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Reporter: Frank Cornelis
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
>
> When I run 'mvn site' I want to generate javadocs for my library. Since I
> have multiple versions of my library, I also want to keep old javadocs, for
> previous versions of my library, available on the site.
> For this I use the destDir configuration parameter, which I set to
> ${project.build.directory}/site/apidocs-${project.version}. That way the
> javadocs indeed get generated under, for example, apidocs-1.3-SNAPSHOT, but
> the generated site still points to the empty apidocs directory.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1788) maven war reports unsatisfied dependency with some jars even though those jars are in the local repository.
[ http://jira.codehaus.org/browse/MAVEN-1788?page=all ] Charles Richard closed MAVEN-1788. -- Resolution: Fixed Found the issue. Didn't realize the repository would be created at $HOME/.maven and the dependencies were missing at this path. Sorry. > maven war reports unsatisfied dependency with some jars even though those > jars are in the local repository. > --- > > Key: MAVEN-1788 > URL: http://jira.codehaus.org/browse/MAVEN-1788 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.0.2 > Environment: Solaris 10 >Reporter: Charles Richard > > I was trying to get scarab to build and it's probably something i did but > there was like 7 jar files that were given in a list of unsatisfied > dependencies when i ran "maven war -Dmaven.test.skip". > I copied those jar files in the local repository and i'm still getting the > same error. I get a download error with mode=online because those jars don't > exist in ibiblio and i get the same error with mode.online=false which truely > baffles me and leaves me wanting to bang my head on something :) > My understanding is that Maven should be checking the local repository first > to see if those jars are there, isn't this correct? The kicker is it doesn't > seem to complain about other jars in the project.xml file. > Thanks, > Charles -- 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: (MJAVADOC-64) No way to output javadoc warnings
[ http://jira.codehaus.org/browse/MJAVADOC-64?page=all ] Vincent Siveton closed MJAVADOC-64. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Applied with getLog().warn() instead of System.out.println() Thanks! > No way to output javadoc warnings > - > > Key: MJAVADOC-64 > URL: http://jira.codehaus.org/browse/MJAVADOC-64 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Kasper Nielsen > Assigned To: Vincent Siveton > Fix For: 2.1 > > Attachments: MJAVADOC-64-fix-for-maven-javadoc-plugin-2.0.patch > > > The javadoc tool outputs javadoc warnings to system.err. However the plugin > eats output from system.err unless the tool exited with an exitCode != 0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-73) provide javadoc warnings
[ http://jira.codehaus.org/browse/MJAVADOC-73?page=all ] Vincent Siveton closed MJAVADOC-73. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Logging has been prefered than file or report (MJAVADOC-64). Felipe, you could create a new issue for your feature. > provide javadoc warnings > > > Key: MJAVADOC-73 > URL: http://jira.codehaus.org/browse/MJAVADOC-73 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Jörg Prante > Assigned To: Vincent Siveton >Priority: Minor > Fix For: 2.1 > > Attachments: javadoc-warnings.diff > > > The Maven javadoc plugin does not provide the warnings given by the javadoc > command. For convenience, it would be nice to save the output of the javadoc > command execution to a file for later examination. A patch for writing a file > "warnings.txt" is attached. -- 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: (MJAVADOC-87) doc-files ignored if they reside in the resources directory
[ http://jira.codehaus.org/browse/MJAVADOC-87?page=all ]
Vincent Siveton closed MJAVADOC-87.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.1
Fixed.
Added a javadoc resource directory. By default, it is
${basedir}/src/main/javadoc
> 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: (MAVENUPLOAD-1111) JasperReports 1.2.6
JasperReports 1.2.6 --- Key: MAVENUPLOAD- URL: http://jira.codehaus.org/browse/MAVENUPLOAD- Project: maven-upload-requests Issue Type: Task Reporter: lucian chirita Java reporting library released under LGPL -- 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-2089) APT & AspectJ plugins
[ http://jira.codehaus.org/browse/MNG-2089?page=comments#action_74046 ] james strachan commented on MNG-2089: - These plugins look great BTW! Juraj - have you figured out how to pass configurations from the plugin into the AnnotationProcessor - such as for the output directory and the like? I wonder if we should contribute this plugin to the Mojo project so that it can be released sooner than Maven (which is released fairly infrequently)? > APT & AspectJ plugins > - > > Key: MNG-2089 > URL: http://jira.codehaus.org/browse/MNG-2089 > Project: Maven 2 > Issue Type: Wish > Components: Sandbox >Affects Versions: 2.0.3 >Reporter: Juraj Burian >Priority: Minor > Fix For: 2.0.5 > > Attachments: APTexamplePrj.zip, plugins.zip > > > We have prototypes of AspectJ & APT plugins ready. > Can you put it into the Sanbox? > Thanx. > best regards > J.Burian -- 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: (MCHANGELOG-48) The link generated in the report contain only one occurrence if a duplicated word is used in the scm repository url.
[ http://jira.codehaus.org/browse/MCHANGELOG-48?page=comments#action_74047
]
Giorgio Urto commented on MCHANGELOG-48:
I have a look at the source code of the class ChangeLogReport.
I believe that the problem is located in the method getAbsolutePath when it
test if ( baseToken.equals( targetRoot ) )
/**
* calculates the path from a base directory to a target file
*
* @param base base directory to create the absolute path from
* @param target target file to create the absolute path to
*/
private String getAbsolutePath( final String base, final String target )
{
String absPath = "";
StringTokenizer baseTokens = new StringTokenizer( base.replaceAll(
"", "/" ), "/", true );
StringTokenizer targetTokens = new StringTokenizer( target.replaceAll(
"", "/" ), "/" );
String targetRoot = targetTokens.nextToken();
while ( baseTokens.hasMoreTokens() )
{
String baseToken = baseTokens.nextToken();
if ( baseToken.equals( targetRoot ) )
{
break;
}
absPath += baseToken;
}
Is this correct?
However a code like the following is better, because in each iteration, the
String is converted to a StringBuffer, appended to, and converted back to a
String. This can lead to a cost quadratic in the number of iterations, as the
growing string is recopied in each iteration.
Better performance can be obtained by using a StringBuffer explicitly. (this
comment is taken from FindBugs)
StringBuffer buf = new StringBuffer();
for (int i = 0; i < field.length; ++i) {
buf.append(field[i]);
}
String s = buf.toString();
Thank You
Giorgio
> The link generated in the report contain only one occurrence if a duplicated
> word is used in the scm repository url.
>
>
> Key: MCHANGELOG-48
> URL: http://jira.codehaus.org/browse/MCHANGELOG-48
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-1
>Reporter: Giorgio Urto
>Priority: Minor
>
> We have chose this svn repository layout
>
>
> .
>
> where is a svn repository, and are directory
> having each one it's trunk, tags and branch.
> If the product have only one component, we have product and component with
> equals names.
> es: http://mysubversion/workarea/lgrefapp/lgrefapp/trunk
> where:
>- workarea is the root directory of all the products
>- the first occurrence of lgrefapp is the product
>- the second occurrence of lgrefapp is the component
>
> The link generated by changelog report contains only one occurrence of
> lgrefapp
> es: http://mysubversion/workarea/lgrefapp/trunk/.
> So the links are broken.
> Thank you
> Giorgio
> Here are my configurations:
>
> http://mysubversion/viewvc/lgrefapp/lgrefapp/trunk
>
> scm:svn:http://mysubversion/workarea/lgrefapp/lgrefapp/trunk
> scm:svn:http://[EMAIL
> PROTECTED]/workarea/lgrefapp/lgrefapp/trunk
>
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.0-SNAPSHOT
>
>
> dual-report
>
> range
> 365
>
>
>
>
> changelog
> file-activity
> dev-activity
>
>
>
>
--
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-2089) APT & AspectJ plugins
[ http://jira.codehaus.org/browse/MNG-2089?page=comments#action_74048 ] james strachan commented on MNG-2089: - Juraj - please ignore my dumbass question about getting access to the output directory from the AnnotationProcessor - I see how to do it now I"ve surfed the APT javadoc :) > APT & AspectJ plugins > - > > Key: MNG-2089 > URL: http://jira.codehaus.org/browse/MNG-2089 > Project: Maven 2 > Issue Type: Wish > Components: Sandbox >Affects Versions: 2.0.3 >Reporter: Juraj Burian >Priority: Minor > Fix For: 2.0.5 > > Attachments: APTexamplePrj.zip, plugins.zip > > > We have prototypes of AspectJ & APT plugins ready. > Can you put it into the Sanbox? > Thanx. > best regards > J.Burian -- 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: (MJAVADOC-77) JavaDoc plug-in fails on IBM AIX JDK
[ http://jira.codehaus.org/browse/MJAVADOC-77?page=all ] Vincent Siveton closed MJAVADOC-77. --- Resolution: Cannot Reproduce It seems to be already handle by the plugin. Have a look to : http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java around the getJavadocPath() method If not, feel free to reopen this issue. > JavaDoc plug-in fails on IBM AIX JDK > > > Key: MJAVADOC-77 > URL: http://jira.codehaus.org/browse/MJAVADOC-77 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Reporter: Sandeep Dixit > > Per the URL below, IBM was using "sh" instead of "bin" as subdirectory name. > This was hardcoded in the JavaDoc task. Apparently at some point, IBM changed > their scheme and went to "bin" instead of "sh" directory. I checked in the > non-websphere JDK and "sh" is a symbolic link (probably for backwards > compatability) to "bin". Because of the previous "sh" problem, the javadoc > task hard-codes AIX for "sh". You should probably look for an updated task > that uses "bin" for AIX instead per the change. > > Below is the URL to old post: > http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fmail-archives.apache.org%2Fmod_mbox%2Fant-dev%2F200112.mbox%2F%253C20011220163331.2303.qmail%40nagoya.betaversion.org%253E&ei=J2B8RNuMJqbepgLouIC-AQ&sig2=DUt4wKsNiOuqDH5b7kfZOQ > Thanks, > Sandeep -- 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: (MJAR-57) Specification and Implementation details missing from manifest
Specification and Implementation details missing from manifest -- Key: MJAR-57 URL: http://jira.codehaus.org/browse/MJAR-57 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Wendy Smoak The manifest customization page claims that Specification and Implementation details will be included in the jar file manifest by default: http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html This does not happen, the default manifest contains only Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: wsmoak Build-Jdk: 1.5.0_05 On the user list, the following configuration was suggested, but it does not produce any additional entries in the manifest. true true -- 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-2089) APT & AspectJ plugins
[ http://jira.codehaus.org/browse/MNG-2089?page=comments#action_74050 ] Jason van Zyl commented on MNG-2089: If you're interested in submitting this then subscribe to the dev@mojo.codehaus.org list and ask for sandbox access. You'll get it and then you can work in the mojo sandbox, get the documentation up to our standard (if it isn't already) and then you can release it. We probably won't host many plugins here at Apache. We encourage new submissions to be made at the Mojo project. > APT & AspectJ plugins > - > > Key: MNG-2089 > URL: http://jira.codehaus.org/browse/MNG-2089 > Project: Maven 2 > Issue Type: Wish > Components: Sandbox >Affects Versions: 2.0.3 >Reporter: Juraj Burian >Priority: Minor > Fix For: 2.0.5 > > Attachments: APTexamplePrj.zip, plugins.zip > > > We have prototypes of AspectJ & APT plugins ready. > Can you put it into the Sanbox? > Thanx. > best regards > J.Burian -- 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: (MJAR-57) Specification and Implementation details missing from manifest
[ http://jira.codehaus.org/browse/MJAR-57?page=comments#action_74051 ] Jason van Zyl commented on MJAR-57: --- So this is a regression then? > Specification and Implementation details missing from manifest > -- > > Key: MJAR-57 > URL: http://jira.codehaus.org/browse/MJAR-57 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > > The manifest customization page claims that Specification and Implementation > details will be included in the jar file manifest by default: > > http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html > This does not happen, the default manifest contains only > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: wsmoak > Build-Jdk: 1.5.0_05 > On the user list, the following configuration was suggested, but it does not > produce any additional entries in the manifest. > > > true > true > > -- 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: (MJAR-57) Specification and Implementation details missing from manifest
[ http://jira.codehaus.org/browse/MJAR-57?page=comments#action_74052 ] Wendy Smoak commented on MJAR-57: - More like: 'new functionality that either doesn't work or is not adequately documented'. :) >From discussion elsewhere, users wanted to be able to prevent >Specification-Title, etc., from appearing in the manifest, so I imagine that's >why the default was changed. That's fine, but now I can't figure out how to get it back in there with . Apparently supplying your own MANIFEST.MF is an option and that will probably be okay as a workaround until this is either fixed, or someone points out what I'm doing wrong. Where are the docs for what is allowed in ? Specifically, inside ? > Specification and Implementation details missing from manifest > -- > > Key: MJAR-57 > URL: http://jira.codehaus.org/browse/MJAR-57 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > > The manifest customization page claims that Specification and Implementation > details will be included in the jar file manifest by default: > > http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html > This does not happen, the default manifest contains only > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: wsmoak > Build-Jdk: 1.5.0_05 > On the user list, the following configuration was suggested, but it does not > produce any additional entries in the manifest. > > > true > true > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1112) upload vraptor 2.1.1
upload vraptor 2.1.1 Key: MAVENUPLOAD-1112 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1112 Project: maven-upload-requests Issue Type: Task Reporter: Guilherme Silveira Its another mvc controller favoring conventions over configuration. It tries to solve some most problems without going to usual solutions as ThreadLocal (i.e. webwork/jsf based solution) for example. -- 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: (MRELEASE-91) Updating of dependencyManagement inconsistent with updating of dependencies with regard to SNAPSHOTs
[ http://jira.codehaus.org/browse/MRELEASE-91?page=comments#action_74061 ] Fabian Bauschulte commented on MRELEASE-91: --- I had the same problem and have tried the patch. I works fine for me. > Updating of dependencyManagement inconsistent with updating of dependencies > with regard to SNAPSHOTs > > > Key: MRELEASE-91 > URL: http://jira.codehaus.org/browse/MRELEASE-91 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: maven 2.0.4, win XP >Reporter: Marcel Schutte > Assigned To: Brett Porter > Fix For: 2.0-beta-4 > > Attachments: changes.xml, depmgnt.zip, MRELEASE-91.patch, > MRELEASE-91.patch-2, release.patch, rewriting-dev-phase.apt, > snapshots-reactor-in-dependencies.tar, > snapshots-reactor-in-dependency-management.tar > > > The mechanism in release:prepare for creating the new development version of > POM's handles snapshots that are part of the current reactor build > differently for dependencyManagement and for dependencies. > A snapshot version in a dependencies section will be updated to the next > development version whereas one in dependencyManagement won't. > The attached patch will change this behavior. It will update a snapshot > version under dependencyManagement if and only if it is part of the current > reactor build. > Note that dependencies cannot contain snapshot versions that are not part of > the current reactor, but dependencyManagement can. I suggest to forbid this > too. > A second suggestion is to introduce a parameter to control the updating of > snapshot dependencies in both dependencyManagement and dependencies sections. > Either leave them at the released version or update them to the new > development version. This touches on the discussion in MRELEASE-36 about the > developer having to knowingly choose to use a new development version. I > would be fine with using a parameter to select the behavior as obtained with > my patch. My central point is that dependencyManagement and dependencies > snapshots should behave the same. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1109) ehcache-1.2.3 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1109?page=all ] Greg Luck updated MAVENUPLOAD-1109: --- Attachment: ehcache-1.2.3-bundle.jar Revised one without clover classes in it > ehcache-1.2.3 bundle > > > Key: MAVENUPLOAD-1109 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1109 > Project: maven-upload-requests > Issue Type: Task >Reporter: Greg Luck > Attachments: ehcache-1.2.3-bundle.jar, ehcache-1.2.3-bundle.jar > > > ehcache-1.2.3 bundle. The tgz was released on sourceforge yesterday. -- 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-1109) ehcache-1.2.3 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1109?page=comments#action_74066 ] Greg Luck commented on MAVENUPLOAD-1109: Please use the smaller of the two files. It was uploaded on 4 September. The larger file contains clover classes. > ehcache-1.2.3 bundle > > > Key: MAVENUPLOAD-1109 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1109 > Project: maven-upload-requests > Issue Type: Task >Reporter: Greg Luck > Attachments: ehcache-1.2.3-bundle.jar, ehcache-1.2.3-bundle.jar > > > ehcache-1.2.3 bundle. The tgz was released on sourceforge yesterday. -- 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: (MJAR-57) Specification and Implementation details missing from manifest
[ http://jira.codehaus.org/browse/MJAR-57?page=comments#action_74067 ] Brett Porter commented on MJAR-57: -- It's not a regression, but a deliberate change. The old default values were crap. I thought I had documented it, but perhaps not. So, the docs need an addition of: a) why it was changed from earlier, and when it was introduced b) the code fragment above (with the tag that is missing around manifest) > Specification and Implementation details missing from manifest > -- > > Key: MJAR-57 > URL: http://jira.codehaus.org/browse/MJAR-57 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > > The manifest customization page claims that Specification and Implementation > details will be included in the jar file manifest by default: > > http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html > This does not happen, the default manifest contains only > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: wsmoak > Build-Jdk: 1.5.0_05 > On the user list, the following configuration was suggested, but it does not > produce any additional entries in the manifest. > > > true > true > > -- 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74070 ] Baerrach bonDierne commented on MNG-2546: - Can you also link to your eclipse pde plugin. Some work like this is being done in the eclipse:eclipse plugin and given the small number of people wanting this specialised functionality it would be great if we could work together. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=all ] Binyan updated MNG-2546: Attachment: MNG-2546-maven-core.patch Patch to add support for the super-init phase that executes plugins before the reactor has sorted the projects. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74072 ] Binyan commented on MNG-2546: - Here is a link to the maven-pde-plugin, http://www.binyan.com/repos/pde. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74073 ] Jason van Zyl commented on MNG-2546: Do you have a test for this as I would probably refactor some bits slightly and would want to make sure everything is still good. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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: (MRM-113) Create a group relocator tool
[ http://jira.codehaus.org/browse/MRM-113?page=all ] Brett Porter updated MRM-113: - Fix Version/s: 1.0-beta-1 > Create a group relocator tool > - > > Key: MRM-113 > URL: http://jira.codehaus.org/browse/MRM-113 > Project: Archiva > Issue Type: New Feature >Reporter: Carlos Sanchez > Fix For: 1.0-beta-1 > > > Migrating old group names to new ones is painful. We need a tool that copies > the artifacts and poms (renaming the group) from the old one to the new one > and then adds relocation info to the old 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
[jira] Updated: (MRM-135) integrate repository sync and conversion in the main application
[ http://jira.codehaus.org/browse/MRM-135?page=all ] Brett Porter updated MRM-135: - Fix Version/s: 1.0 > integrate repository sync and conversion in the main application > > > Key: MRM-135 > URL: http://jira.codehaus.org/browse/MRM-135 > Project: Archiva > Issue Type: New Feature > Components: repository-converter, partner sync, scheduling >Reporter: Brett Porter > Fix For: 1.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-149) create an access log for the proxy
[ http://jira.codehaus.org/browse/MRM-149?page=all ] Brett Porter updated MRM-149: - Fix Version/s: 1.0 > create an access log for the proxy > -- > > Key: MRM-149 > URL: http://jira.codehaus.org/browse/MRM-149 > Project: Archiva > Issue Type: Task > Components: remote proxy >Reporter: Brett Porter > Fix For: 1.0 > > > currently we just log some information to the standard logger, however the > granularity should be improved, and we possibly should track more information > such as which repositories it failed from. This could be done with a custom > plexus logger, or perhaps a separate interface that stores information by > field to be able to search and analyse it without processing the log file. > We may also want to track traditional user fields such as user agent, ip, etc > like a normal access log. -- 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74074 ] Jason van Zyl commented on MNG-2546: Are you going to put the PDE plugin at Eclipse? We definitely can get you hooked up at the Mojo project. Would this plugin also work for OSGi bundles in general? > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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-161) implement a reporting manager
implement a reporting manager - Key: MRM-161 URL: http://jira.codehaus.org/browse/MRM-161 Project: Archiva Issue Type: Task Components: reporting Reporter: Brett Porter we need a central place to log issues that go into the report interface -- 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-162) implement "quick fix" capabilities in reports
implement "quick fix" capabilities in reports - Key: MRM-162 URL: http://jira.codehaus.org/browse/MRM-162 Project: Archiva Issue Type: Task Components: reporting Reporter: Brett Porter see the white site - checksums need to be generated/corrected, duplicate files might be removed or relocated, etc. -- 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] Reopened: (MAVEN-1788) maven war reports unsatisfied dependency with some jars even though those jars are in the local repository.
[ http://jira.codehaus.org/browse/MAVEN-1788?page=all ] Lukas Theussl reopened MAVEN-1788: -- > maven war reports unsatisfied dependency with some jars even though those > jars are in the local repository. > --- > > Key: MAVEN-1788 > URL: http://jira.codehaus.org/browse/MAVEN-1788 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.0.2 > Environment: Solaris 10 >Reporter: Charles Richard > > I was trying to get scarab to build and it's probably something i did but > there was like 7 jar files that were given in a list of unsatisfied > dependencies when i ran "maven war -Dmaven.test.skip". > I copied those jar files in the local repository and i'm still getting the > same error. I get a download error with mode=online because those jars don't > exist in ibiblio and i get the same error with mode.online=false which truely > baffles me and leaves me wanting to bang my head on something :) > My understanding is that Maven should be checking the local repository first > to see if those jars are there, isn't this correct? The kicker is it doesn't > seem to complain about other jars in the project.xml file. > Thanks, > Charles -- 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: (MAVEN-1788) maven war reports unsatisfied dependency with some jars even though those jars are in the local repository.
[ http://jira.codehaus.org/browse/MAVEN-1788?page=all ] Lukas Theussl closed MAVEN-1788. Resolution: Won't Fix Please consult the mailing list first next time, only open issues if you are sure you have found a bug. Thanks! > maven war reports unsatisfied dependency with some jars even though those > jars are in the local repository. > --- > > Key: MAVEN-1788 > URL: http://jira.codehaus.org/browse/MAVEN-1788 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.0.2 > Environment: Solaris 10 >Reporter: Charles Richard > > I was trying to get scarab to build and it's probably something i did but > there was like 7 jar files that were given in a list of unsatisfied > dependencies when i ran "maven war -Dmaven.test.skip". > I copied those jar files in the local repository and i'm still getting the > same error. I get a download error with mode=online because those jars don't > exist in ibiblio and i get the same error with mode.online=false which truely > baffles me and leaves me wanting to bang my head on something :) > My understanding is that Maven should be checking the local repository first > to see if those jars are there, isn't this correct? The kicker is it doesn't > seem to complain about other jars in the project.xml file. > Thanks, > Charles -- 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: (MPTEST-71) maven test stops the build at the first test failure
[ http://jira.codehaus.org/browse/MPTEST-71?page=all ] Lukas Theussl updated MPTEST-71: Fix Version/s: (was: 1.8) 1.8.1 > maven test stops the build at the first test failure > > > Key: MPTEST-71 > URL: http://jira.codehaus.org/browse/MPTEST-71 > Project: maven-test-plugin > Issue Type: Bug >Reporter: Pascal Grange > Assigned To: Lukas Theussl > Fix For: 1.8.1 > > > The fix for MPTEST-25 has a behavioral side effect that I consider as a bug. > Before the fix, any test failure would halt the whole testing process, unless > the failure.ignore was specified. Now, no matter what you do, the complete > test suite will run eventhough you want it to stop at the first error it > encounters. > http://jira.codehaus.org/browse/MPTEST-25 > Thanks, > Seb -- 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: (MPTEST-70) no security debug log information after set maven.junit.jvmargs=-Djava.security.debug=all
[ http://jira.codehaus.org/browse/MPTEST-70?page=all ] Lukas Theussl updated MPTEST-70: Fix Version/s: 1.8.1 > no security debug log information after set > maven.junit.jvmargs=-Djava.security.debug=all > - > > Key: MPTEST-70 > URL: http://jira.codehaus.org/browse/MPTEST-70 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Build/running Apache AXIS2 testcase with maven 1.1.3 >Reporter: Ming Cheung >Priority: Critical > Fix For: 1.8.1 > > > I added the following 2 maven properties to"project.properties" file under > axis2/modules/kernel/ directory. and do not see any securitty related logging > information in the trace file. Similarly, the second part of the > maven.junit.jvmargs, which is the specific policy file, mytestpolicy.policy, > is also not loaded to the JVM. > -- > maven.junit.fork=true > maven.junit.jvmargs=-Djava.security.debug=all > -Djava.security.policy=c:/temp/mytestpolicy.policy > -- > To reproducing this problem is quite simple and straight forward. > You can just use a simple testcase (any testcase is fine and no need to have > any security codes) from your own; Add the 2 above properties to the > project.properties file. then run the maven with your test. > Usually, if you see the log contains the "SCL" keywords, the security debug > is being picked and used. otherwise, it is not. > Security log output example: > -- > scl: (Thread[main,5,main]) getPermissions ProtectionDomain > (file:/C:/Documents%20and%20Settings/mingcheu/ ) > [EMAIL PROTECTED] > > [EMAIL PROTECTED] ( > (java.lang.RuntimePermission exitVM) > (java.io.FilePermission \C:\Documents and Settings\mingcheu\- read) > ) > scl: (Thread[main,5,main]) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1125) ant:java fork issues
[ http://jira.codehaus.org/browse/MAVEN-1125?page=all ] Lukas Theussl updated MAVEN-1125: - Fix Version/s: 1.1-rc1 > ant:java fork issues > > > Key: MAVEN-1125 > URL: http://jira.codehaus.org/browse/MAVEN-1125 > Project: Maven > Issue Type: Bug >Affects Versions: 1.0-rc2 > Environment: Linux, JDK1.4.2 >Reporter: Andy Jefferson > Assigned To: Arnaud Heritier > Fix For: 1.1-rc1 > > Attachments: maven-console-test.jar > > > I have a Java app that I want to invoke via Maven. The Java app uses stdin > and stdout. > If I invoke using ant:java using "fork=true" then stdin doesn not respond > correctly. That is, the app prompts, but the user can type to their hearts > content and nothing reaches the app. > If I invoke using ant:java using "fork=false" then I get strange XML related > errors about unresolved references org/w3c/dom/Node, org/w3c/dom/Document -- 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: (MPWAR-65) Problems with maven.war.property.expansion
[ http://jira.codehaus.org/browse/MPWAR-65?page=all ] Lukas Theussl updated MPWAR-65: --- Fix Version/s: 1.6.3 > Problems with maven.war.property.expansion > -- > > Key: MPWAR-65 > URL: http://jira.codehaus.org/browse/MPWAR-65 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: Caleb Lyness > Fix For: 1.6.3 > > > When you use the maven.war.property.expansion=true, all resources in your > webapps folder are all modified. This is fine, but some binary files (for > example image) are broken in the process. I would propose that 2 variable are > added, apon which the filter set can be further specified. > maven.war.property.expansion.includes > maven.war.property.expansion.excludes > In this way specific files may have the expansion applied to them or avoid > any meddling. > Also, note that the special treatment of web.xml conflicts with the > maven.war.property.expansion. > The web.xml is copied and filtered during the main copy step (including > expansion). Then later > it is copied again, without expansion, overwritting the original file. This > can be worked around by > setting maven.war.webxml=nonexistentfile or by having > maven.war.webxml.overwrite=false > The expansion code should be added to the second stage as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPECLIPSE-102) Running 'maven:eclipse' turns CheckStyle off for the project.
[ http://jira.codehaus.org/browse/MPECLIPSE-102?page=all ] Lukas Theussl updated MPECLIPSE-102: Assignee: Stephane Nicoll Fix Version/s: 1.11.1 > Running 'maven:eclipse' turns CheckStyle off for the project. > - > > Key: MPECLIPSE-102 > URL: http://jira.codehaus.org/browse/MPECLIPSE-102 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Jamie Bisotti > Assigned To: Stephane Nicoll > Fix For: 1.11.1 > > > Assuming project is already setup in Eclipse 3.1 (either manually or via the > eclipse plugin) > 1. Install CheckStyle Eclispe plugin > 2. Turn it on for the project. > 3. Shutdown Eclipse > 4. Run maven eclipse on the project > 5. Restart Eclipse > 6. Notice CheckStyle is now turned off. -- 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=comments#action_74080 ] Binyan commented on MNG-2546: - I just today asked on the Eclipse PDE list about where I could move this plugin so it could get more exposure and use cases to flush it out more. Personally, I don't have a preference. If it is too come to under the apache license I will need to see about a couple of classes that were provided to me for an EPL project. I don't think they will e an issue with changing the license of those classes, but I'll ask and see. And yes, the plugin works for OSGi bundles. As for the patch I have an example set of projects I use for testing the maven-pde-plugin. Once I cleanup the code I'll see if I can create a maven test for it. However, feel free to make the small tweaks, I can test it out faster than I can likely learn how to create a maven test. > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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: (MPCHECKSTYLE-36) Generate an Eclipse formatter profile from checkstyle config
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-36?page=all ] Lukas Theussl closed MPCHECKSTYLE-36. - Resolution: Duplicate > Generate an Eclipse formatter profile from checkstyle config > > > Key: MPCHECKSTYLE-36 > URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-36 > Project: maven-checkstyle-plugin > Issue Type: New Feature >Reporter: Marc Guillemot >Priority: Minor > > I'm not sure if it is more related to the checkstyle plugin or to the Eclipse > plugin. > It would be interesting to generate from checkstyle configuration file a > "formatter profile" that can be imported in Eclipse (Preferences / Java / > Code Style / Formatter / Import...) -- 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: (MRM-161) implement a reporting manager
[ http://jira.codehaus.org/browse/MRM-161?page=all ] Brett Porter updated MRM-161: - Remaining Estimate: 4 hours Original Estimate: 4 hours > implement a reporting manager > - > > Key: MRM-161 > URL: http://jira.codehaus.org/browse/MRM-161 > Project: Archiva > Issue Type: Task > Components: reporting >Reporter: Brett Porter > Assigned To: Brett Porter > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > we need a central place to log issues that go into the report interface -- 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: (MPEAR-46) Unknown artifact type[java-source]
[ http://jira.codehaus.org/browse/MPEAR-46?page=all ] Lukas Theussl updated MPEAR-46: --- Fix Version/s: 1.9.1 > Unknown artifact type[java-source] > --- > > Key: MPEAR-46 > URL: http://jira.codehaus.org/browse/MPEAR-46 > Project: maven-ear-plugin > Issue Type: Bug > Environment: Windows > Eclipse 3.1 >Reporter: Tom Bollwitt >Priority: Trivial > Fix For: 1.9.1 > > > When a POM (parent or dependency) includes java source jar dependencies they > are not ignored and an error is thrown. > > mygroup > artifact2 > 1.0 > java-source > > When running 'package' or ear:ear I am getting the following error: > [INFO] [ear:generate-application-xml] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to initialize ear modules > Embedded error: Unknown artifact type[java-source] > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to initialize > ear modules > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to > initialize ear modules > at > org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:151) > at > org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown > artifact type[java-source] > at > org.apache.maven.plugin.ear.ArtifactTypeMappingService.getStandardType(ArtifactTypeMappingService.java:153) > at > org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:60) > at > org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:144) > ... 19 more > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Aug 30 11:49:59 CDT 2006 > [INFO] Final Memory: 4M/7M > I added test to the java-source dependency and was able to > work around this issue. The scope is missleading and therefore the desired > behavior would be to not require scoping the java-source dependency. -- 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: (MPSCM-86) scm:prepare-release does not commit modified changes.xml
[ http://jira.codehaus.org/browse/MPSCM-86?page=comments#action_74081 ] Chuck Daniels commented on MPSCM-86: That would explain it for me. My value for maven.docs.src is src/site/xdoc. What other information do you need? > scm:prepare-release does not commit modified changes.xml > > > Key: MPSCM-86 > URL: http://jira.codehaus.org/browse/MPSCM-86 > Project: maven-scm-plugin > Issue Type: Bug >Affects Versions: 1.6 > Environment: Windows 2000 >Reporter: Chuck Daniels >Priority: Minor > Fix For: 1.6.1 > > > The scm:prepare-release goal does not commit the change it makes to > changes.xml. However, it does properly put the modified changes.xml file into > the new tag and it does commit the changes to project.xml. > This requires a manual commit to changes.xml after running > scm:prepare-release. Is this the intention? -- 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: (MPSCM-86) scm:prepare-release does not commit modified changes.xml
[ http://jira.codehaus.org/browse/MPSCM-86?page=comments#action_74082 ] Lukas Theussl commented on MPSCM-86: None. :) I'd just ask you to watch this issue, as soon as we get around to fix it we'll publish a snapshot and it'd be good to have it tested then. Thanks! > scm:prepare-release does not commit modified changes.xml > > > Key: MPSCM-86 > URL: http://jira.codehaus.org/browse/MPSCM-86 > Project: maven-scm-plugin > Issue Type: Bug >Affects Versions: 1.6 > Environment: Windows 2000 >Reporter: Chuck Daniels >Priority: Minor > Fix For: 1.6.1 > > > The scm:prepare-release goal does not commit the change it makes to > changes.xml. However, it does properly put the modified changes.xml file into > the new tag and it does commit the changes to project.xml. > This requires a manual commit to changes.xml after running > scm:prepare-release. Is this the intention? -- 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: (MPSCM-37) can't change read-only project.xml
[ http://jira.codehaus.org/browse/MPSCM-37?page=all ] Lukas Theussl closed MPSCM-37. -- Assignee: Lukas Theussl Resolution: Duplicate Fix Version/s: (was: 1.7) > can't change read-only project.xml > -- > > Key: MPSCM-37 > URL: http://jira.codehaus.org/browse/MPSCM-37 > Project: maven-scm-plugin > Issue Type: Bug >Affects Versions: 1.4.1 > Environment: maven 1.0.2 + CVSNT >Reporter: Emilio Jose Mena Cebrian > Assigned To: Lukas Theussl >Priority: Minor > > SCM plgin can't change project.xml when the module has watches enabled (with > 'cvs watch on' command). > when watches are enabled, all the files into the module are checked out > read-only. So, SCM plugin can't change project.xml. Therefore prepare-release > goal doesn't work properly. -- 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: (MJAR-57) Specification and Implementation details missing from manifest
[ http://jira.codehaus.org/browse/MJAR-57?page=comments#action_74085 ] Bugittaa Pahasti commented on MJAR-57: -- The solution suggested by Brett does work: true true So this seems to be only documentation issue. > Specification and Implementation details missing from manifest > -- > > Key: MJAR-57 > URL: http://jira.codehaus.org/browse/MJAR-57 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > > The manifest customization page claims that Specification and Implementation > details will be included in the jar file manifest by default: > > http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html > This does not happen, the default manifest contains only > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: wsmoak > Build-Jdk: 1.5.0_05 > On the user list, the following configuration was suggested, but it does not > produce any additional entries in the manifest. > > > true > true > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=all ] Carlos Sanchez closed CONTINUUM-771. Assignee: Carlos Sanchez (was: Henry S. Isidro) Resolution: Fixed > Add user management screens > --- > > Key: CONTINUUM-771 > URL: http://jira.codehaus.org/browse/CONTINUUM-771 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-771-continuum-webapp-menu.patch, > CONTINUUM-771-continuum-webapp-refactored_user_management_actions.patch, > CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch, > CONTINUUM-771-continuum-webapp-with-improved-logging.patch, > CONTINUUM-771-continuum-webapp.patch, CONTINUUM-771-continuum-webapp.patch > > > Add a page for listing the users, with options to add/edit/delete user > Users can have an unlimited number of roles (Continuum Permission) like > addProject, addUser,... they are already created by the ContinuumInitializer > and are static (no new roles/permissions can be added) -- 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: (CONTINUUM-843) Add user form for self editing user details
Add user form for self editing user details --- Key: CONTINUUM-843 URL: http://jira.codehaus.org/browse/CONTINUUM-843 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-843) Add user form for self editing user details
[ http://jira.codehaus.org/browse/CONTINUUM-843?page=all ] Carlos Sanchez updated CONTINUUM-843: - Assignee: Carlos Sanchez Description: Users should be able to edit its own details (like email) and change their password Of course thay can't edit their permissions or username Reuse as much as possible the edit user page already done for administrators Make sure the user id / username is not passed as argument anywhere, it must be retrieved by the UserManager object, to avoid dependency on acegi in maven-user-core i'm gonna create an interface there and add an implementation in maven-user-acegi Fix Version/s: 1.1 Component/s: Web interface > Add user form for self editing user details > --- > > Key: CONTINUUM-843 > URL: http://jira.codehaus.org/browse/CONTINUUM-843 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > > Users should be able to edit its own details (like email) and change their > password > Of course thay can't edit their permissions or username > Reuse as much as possible the edit user page already done for administrators > Make sure the user id / username is not passed as argument anywhere, it must > be retrieved by the UserManager object, to avoid dependency on acegi in > maven-user-core i'm gonna create an interface there and add an implementation > in maven-user-acegi -- 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: (CONTINUUM-844) Add user permission edit form in project group page
Add user permission edit form in project group page --- Key: CONTINUUM-844 URL: http://jira.codehaus.org/browse/CONTINUUM-844 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-441) Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature
Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature --- Key: MEV-441 URL: http://jira.codehaus.org/browse/MEV-441 Project: Maven Evangelism Issue Type: Bug Reporter: Patrick Moore I am trying to use the version range feature that is talked about in Better builds with Maven. I am specifying the commons-httpclient dependency as commons-httpclient commons-httpclient [3.1-alpha1,) Unfortunately, the usefulness of this feature is being sabotaged in 2 ways. 1) maven-metadata.xml in the commons-httpclient directory does not list version 3.1-alpha1. This means that it will not find that version. 2) maven-metadata.xml lists a "20020423" which is numerically the highest number version, so my build is picking up this very old version. Other projects with this problem include: commons-chain and jmock. -- 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: (CONTINUUM-844) Add user permission edit form in project group page
[ http://jira.codehaus.org/browse/CONTINUUM-844?page=all ] Carlos Sanchez updated CONTINUUM-844: - Description: In whatever page currently present for view or edit project groups, add a form to set per user and per project group permissions It needs to show the list of users and something like checkboxes for each permission Permissions are: * View * Edit * Delete * Build Affects Version/s: 1.1 Component/s: Web interface > Add user permission edit form in project group page > --- > > Key: CONTINUUM-844 > URL: http://jira.codehaus.org/browse/CONTINUUM-844 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Affects Versions: 1.1 >Reporter: Carlos Sanchez > > In whatever page currently present for view or edit project groups, add a > form to set per user and per project group permissions > It needs to show the list of users and something like checkboxes for each > permission > Permissions are: > * View > * Edit > * Delete > * Build -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
