[jira] Updated: (MAVENUPLOAD-1001) Stopwatch
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1001?page=all ] Milen Dyankov updated MAVENUPLOAD-1001: --- Attachment: stopwatch-0.3-bundle.jar POM with no parent > Stopwatch > - > > Key: MAVENUPLOAD-1001 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1001 > Project: maven-upload-requests > Issue Type: Task >Reporter: Milen Dyankov > Attachments: stopwatch-0.3-bundle.jar, stopwatch-0.3-bundle.jar > > > http://prdownloads.sourceforge.net/jstopwatch/stopwatch-0.3.jar?download > http://jstopwatch.sourceforge.net > http://jstopwatch.sourceforge.net/team-list.html > Stopwatch is a free, simple, highly extensible, Java API that allows > developers to easily monitor > whole application or any part of it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-164) Typo error in website documentation on how to deploy a site
Typo error in website documentation on how to deploy a site --- Key: MSITE-164 URL: http://jira.codehaus.org/browse/MSITE-164 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Valerio Schiavoni It is: -- 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: (MSITE-165) Typo error in website documentation on how to deploy a site
Typo error in website documentation on how to deploy a site --- Key: MSITE-165 URL: http://jira.codehaus.org/browse/MSITE-165 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Valerio Schiavoni Attachments: maven-site-usage-typo.diff It is: mvn site-deploy and it should be: mvn site:deploy Attached the unidiff. -- 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: (ARCHETYPE-40) Duplicate code in portlet archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-40?page=all ] Franz Allan Valencia See updated ARCHETYPE-40: -- Attachment: maven-archetype-portlet.patch Removed duplication from all files except the project's root pom. In archetype.xml added "src/main/webapp/WEB-INF/tld/portlet.tld" > Duplicate code in portlet archetype > --- > > Key: ARCHETYPE-40 > URL: http://jira.codehaus.org/browse/ARCHETYPE-40 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Reporter: Craig Doremus > Attachments: maven-archetype-portlet.patch > > > The maven portlet archetype (maven-archetype-portlet under > maven-archetype-bundles) in source control contains duplicate code in all > files except the root pom.xml. The code for a file appears to be copied into > the file multiple times in every source file in each directory, rendering the > archetype to be unusable. > The fix is pretty evident when one looks at the source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-164) Typo error in website documentation on how to deploy a site
[ http://jira.codehaus.org/browse/MSITE-164?page=all ] Valerio Schiavoni closed MSITE-164. --- Resolution: Incomplete a complete version is at http://jira.codehaus.org/browse/MSITE-165 > Typo error in website documentation on how to deploy a site > --- > > Key: MSITE-164 > URL: http://jira.codehaus.org/browse/MSITE-164 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Valerio Schiavoni > > It is: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-133) Create launch configuration for JUnit tests
Create launch configuration for JUnit tests --- Key: MECLIPSE-133 URL: http://jira.codehaus.org/browse/MECLIPSE-133 Project: Maven 2.x Eclipse Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Joerg Schaible Priority: Minor To run the JUnit tests of a project in Eclipse you can click right on the source folder with the unit tests and run them as Junit test. Left over from this action is typically a run configuration named "java". It would be nice, if the plugin could generate such a launch configuration automatically as shared launch configuration and name it properly e.g. -junit. With such a setup, the configuration is automatically available, when the project is open. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-165) Typo error in website documentation on how to deploy a site
[ http://jira.codehaus.org/browse/MSITE-165?page=all ] Brett Porter closed MSITE-165. -- Assignee: Brett Porter Resolution: Won't Fix site-deploy is correct (it's the phase that is part of the site lifecycle, to which site:deploy is bound. If you run site:deploy, then the site is not generated). > Typo error in website documentation on how to deploy a site > --- > > Key: MSITE-165 > URL: http://jira.codehaus.org/browse/MSITE-165 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Valerio Schiavoni > Assigned To: Brett Porter > Attachments: maven-site-usage-typo.diff > > > It is: > mvn site-deploy > and it should be: > mvn site:deploy > Attached the unidiff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-130) extra empty lines are preserved when writing Manifest.mf file
[ http://jira.codehaus.org/browse/MECLIPSE-130?page=all ] stephane bouchet updated MECLIPSE-130: -- Attachment: MECLIPSE_130_patch.diff Hi, In attachment, tha patch to avoid empty line to be written. It's just a test added when re-writting manifest File. Cheers, Stéphane > extra empty lines are preserved when writing Manifest.mf file > - > > Key: MECLIPSE-130 > URL: http://jira.codehaus.org/browse/MECLIPSE-130 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.3 > Environment: Windows Xp, eclipse 3.2.0, jdk 1.5, maven 2.0.4 >Reporter: stephane bouchet >Priority: Minor > Attachments: MECLIPSE_130_patch.diff > > > Hi, > when i use the last snapshot in pde projects, i notice that bug : > the Bundle:Classpath entry is written in the end of the file, but if there is > empty line before writing this entry, they are not removed. > So eclipse complains about it. > To resolve this, i had to manually delete these empty lines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-131) Attach source and javadoc to dependencies in pde projects
[ http://jira.codehaus.org/browse/MECLIPSE-131?page=comments#action_70493 ] stephane bouchet commented on MECLIPSE-131: --- Hi, It seems that the last snapshot corrected this issue. Can you confirm it ??? Cheers, Stéphane > Attach source and javadoc to dependencies in pde projects > - > > Key: MECLIPSE-131 > URL: http://jira.codehaus.org/browse/MECLIPSE-131 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 > Environment: windows xp, eclipse3.2.0, jdk 1.5, maven 2.0.4 >Reporter: stephane bouchet > > when using plugin for pde projects, source and javadoc are not attached for > dependencies even if they are available in repo. > this feature exists already for java project, it could be nice to have the > same for pde projects. > Thanks, > Stéphane . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-131) Attach source and javadoc to dependencies in pde projects
[ http://jira.codehaus.org/browse/MECLIPSE-131?page=all ] fabrizio giustina closed MECLIPSE-131. -- Assignee: fabrizio giustina Resolution: Fixed Fix Version/s: 2.3 yes, this has just been fixed in svn > Attach source and javadoc to dependencies in pde projects > - > > Key: MECLIPSE-131 > URL: http://jira.codehaus.org/browse/MECLIPSE-131 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 > Environment: windows xp, eclipse3.2.0, jdk 1.5, maven 2.0.4 >Reporter: stephane bouchet > Assigned To: fabrizio giustina > Fix For: 2.3 > > > when using plugin for pde projects, source and javadoc are not attached for > dependencies even if they are available in repo. > this feature exists already for java project, it could be nice to have the > same for pde projects. > Thanks, > Stéphane . -- 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-1009) Upload JGoodies looks 2.0.4
Upload JGoodies looks 2.0.4 --- Key: MAVENUPLOAD-1009 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1009 Project: maven-upload-requests Issue Type: Task Reporter: Emmanuel Venisse -- 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-771) Add user management screens
[ http://jira.codehaus.org/browse/CONTINUUM-771?page=comments#action_70500
]
Carlos Sanchez commented on CONTINUUM-771:
--
Applied again for missing files.
Other comments:
Year of copyright must be {year created}-{year last modified}, so for new files
it must be just 2006
Missing javadoc comments in action classes
All other classes have the @version $Id$ tag, so it must be added too for
consistency
> 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: Henry S. Isidro
> Fix For: 1.1
>
> Attachments:
> CONTINUUM-771-continuum-webapp-using-PlexusActionSupport.patch,
> CONTINUUM-771-continuum-webapp-with-improved-logging.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] Updated: (CONTINUUM-779) Creation of AbstractActionLogger that extends ActionSupport and implements LogEnabled
[ http://jira.codehaus.org/browse/CONTINUUM-779?page=all ] Carlos Sanchez updated CONTINUUM-779: - Attachment: CONTINUUM-779.patch Updated patch against trunk. Comments: remove the e.printStackTrace commands, that will print them on stdout when exceptions are not rethrown again, use log.x(String , Exception ) instead of log.x(String), that way the exception stacktrace will be printed in the logger. If they are rethrown again you don't want to log them, they must be logged in another layer that catches them addActionError must be used with a meaningful error for the user, eg. "your user id already exists, please choose another", never something like "jdbc error xx", so never append the exception message there. Related to previous is CONTINUUM-778, where we try to avoid dealing with internal errors outside of actions, so most of the exception handling code in actions probably will be removed. > Creation of AbstractActionLogger that extends ActionSupport and implements > LogEnabled > - > > Key: CONTINUUM-779 > URL: http://jira.codehaus.org/browse/CONTINUUM-779 > Project: Continuum > Issue Type: Sub-task >Reporter: Teodoro Cue Jr. > Attachments: AXPENTBUILDENV-60-continuum-webapp.patch, > CONTINUUM-779.patch > > > A class that will be use by all actions. This is to eliminate code repetition > when actions implements the LogEnabled 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: (CONTINUUM-779) Creation of AbstractActionLogger that extends ActionSupport and implements LogEnabled
[ http://jira.codehaus.org/browse/CONTINUUM-779?page=all ] Carlos Sanchez updated CONTINUUM-779: - Attachment: (was: AXPENTBUILDENV-60-continuum-webapp.patch) > Creation of AbstractActionLogger that extends ActionSupport and implements > LogEnabled > - > > Key: CONTINUUM-779 > URL: http://jira.codehaus.org/browse/CONTINUUM-779 > Project: Continuum > Issue Type: Sub-task >Reporter: Teodoro Cue Jr. > Attachments: CONTINUUM-779.patch > > > A class that will be use by all actions. This is to eliminate code repetition > when actions implements the LogEnabled 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: (MCHECKSTYLE-49) Review and revise plugin documentation
[ http://jira.codehaus.org/browse/MCHECKSTYLE-49?page=all ] Dennis Lundberg updated MCHECKSTYLE-49: --- Attachment: documentation.patch Fixed a couple of minor typos and changed "checkstyle" to "Checkstyle" in a number of places. > Review and revise plugin documentation > -- > > Key: MCHECKSTYLE-49 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-49 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: documentation.patch > > Original Estimate: 22 hours > Time Spent: 22 hours > Remaining Estimate: 0 minutes > -- 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: (MRELEASE-141) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MRELEASE-141?page=all ] John Tolentino updated MRELEASE-141: Due Date: 27/Jul/06 (was: 24/Jul/06) > Review Plugin Documentation > --- > > Key: MRELEASE-141 > URL: http://jira.codehaus.org/browse/MRELEASE-141 > Project: Maven 2.x Release Plugin > Issue Type: Task >Affects Versions: 2.0 >Reporter: John Tolentino > Assigned To: John Tolentino > Original Estimate: 1 day, 7 hours > Time Spent: 1 day > Remaining Estimate: 7 hours > > Add examples and FAQs, pass docck, fix navigation and home page to conform > with plugin documentation standards. -- 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-125) make discovery only discover new artifacts
[ http://jira.codehaus.org/browse/MRM-125?page=all ] Brett Porter closed MRM-125. Resolution: Fixed > make discovery only discover new artifacts > -- > > Key: MRM-125 > URL: http://jira.codehaus.org/browse/MRM-125 > Project: Maven Repository Manager > Issue Type: Bug > Components: discovery >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 3 hours > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > currently every artifact is discovered every time. A technique that > facilitates only finding new artifacts is needed. > Note gotchas: > - different operations will run at different times, so there can't be a > single repository discovery timestamp. For example, indexing might check > based on the last time the index was updated > - some operations are not atomic (eg indexing may not complete, but the index > is newer than some artifacts created afterwards, and artifacts created > between discovery and indexing will fall through the cracks) > I'd suggest narrowing down the times to some atomic operations (eg, updating > index for all new artifacts, where index is only written at the end), and > tracking the timestamp based on the conclusion of discovery, not the > operation, then recording those timestamps in a metadata file in the root of > the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-65) Version of parent pom in doxia doc renderer is not updated in svn
[ http://jira.codehaus.org/browse/DOXIA-65?page=all ] Vincent Siveton closed DOXIA-65. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 Done in svn r424255 > Version of parent pom in doxia doc renderer is not updated in svn > - > > Key: DOXIA-65 > URL: http://jira.codehaus.org/browse/DOXIA-65 > Project: doxia > Issue Type: Bug > Environment: maven 2.1-snapshot >Reporter: Maria Odea Ching > Assigned To: Vincent Siveton > Fix For: 1.0 > > Attachments: doxia-65.patch > > > Version should be 1.0-alpha-9-SNAPSHOT instead of 1.0-alpha-8-SNAPSHOT. -- 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: (DOXIA-66) Version of parent pom in doxia editor is not updated in svn. Also the doxia core dependency.
[ http://jira.codehaus.org/browse/DOXIA-66?page=all ] Vincent Siveton closed DOXIA-66. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 Done in svn r424255 > Version of parent pom in doxia editor is not updated in svn. Also the doxia > core dependency. > > > Key: DOXIA-66 > URL: http://jira.codehaus.org/browse/DOXIA-66 > Project: doxia > Issue Type: Bug > Environment: maven 2.1-snapshot >Reporter: Maria Odea Ching > Assigned To: Vincent Siveton > Fix For: 1.0 > > Attachments: DOXIA-66.patch > > > Parent pom version should be 1.0-alpha-9-SNAPSHOT instead of > 1.0-alpha-8-SNAPSHOT. > doxia core dependency version should be 1.0-alpha-8 instead of > 1.0-alpha-8-SNAPSHOT. -- 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: (DOXIA-53) Pdf and Rtf support with the iText framework
[ http://jira.codehaus.org/browse/DOXIA-53?page=all ] Vincent Siveton closed DOXIA-53. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 Added by Jason in svn r406450 > Pdf and Rtf support with the iText framework > > > Key: DOXIA-53 > URL: http://jira.codehaus.org/browse/DOXIA-53 > Project: doxia > Issue Type: New Feature >Reporter: Vincent Siveton > Assigned To: Vincent Siveton > Fix For: 1.0 > > Attachments: doxia_itext.zip, generated-doc.zip, itext_plugin.zip > > > Propose a Pdf/Rtf support with the iText framework for Doxia. > Here is the architecture: > - added an itext module in doxia-modules > - created a doxia-doc-renderer (similar to doxia-site-renderer) > - created an iText plugin for maven > The iText module generates iText XML files. So, documents should be generated > in Pdf or Rtf format (supported by iText). > You could see the howto in the plugin for more information or try the project > tests. > According MPIR-17, we could be more generic by defining a new generated XML > Doxia (I mean another DoxiaSink) and apply XSLT to generate other formats > (like javahelp) > Known limitations: > - known limitations from the iText framework like roman list > - i18n for the "table of contents" title > - reports are not supported > - Renderer for Fml and Xdoc format should be improved. Parsers suppose that > the renderer is HTML. > Attachments are: > - doxia zip with diff (containing doxia-doc-renderer and doxia-module-itext) > and resources > - itext plugin zip with diff and resources > - a zip containing generated documents for the site project (real examples) -- 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: (DOXIA-40) Request for a TOC-like feature
[ http://jira.codehaus.org/browse/DOXIA-40?page=comments#action_70512 ] Vincent Siveton commented on DOXIA-40: -- FYI, Trygve Laugstol commits a doxia-book project to make books in Doxia. http://svn.apache.org/viewvc/maven/doxia/trunk/doxia-sandbox/doxia-book/ > Request for a TOC-like feature > -- > > Key: DOXIA-40 > URL: http://jira.codehaus.org/browse/DOXIA-40 > Project: doxia > Issue Type: New Feature >Reporter: Anuerin Diaz >Priority: Minor > > If it is possible, I would like to request for a TOC like functionality that > will generate links to certain headers (section, subsection, etc) on the > 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] Commented: (WAGONFTP-10) NPE in wagon-ftp
[ http://jira.codehaus.org/browse/WAGONFTP-10?page=comments#action_70518 ]
Oliver Fink commented on WAGONFTP-10:
-
Actually after a lot of playing around, I've found out the following (for the
maven anttasks)
* settings.xml seem to be happily ignored
* ftp only works if authentication is declared with the remote repository
*inside* the {{artifact:deploy}} task. If it is declared outside and referenced
by a {{refid}} authentication won't work
> NPE in wagon-ftp
>
>
> Key: WAGONFTP-10
> URL: http://jira.codehaus.org/browse/WAGONFTP-10
> Project: wagon-ftp
> Issue Type: Bug
>Affects Versions: 1.0-alpha-6
> Environment: linux 2.6.7, jdk 1.4.2, maven 2.0.2
>Reporter: Jean-Laurent de Morlhon
>Priority: Minor
>
> When deploying a pom project to an ftp repository there is an NPE see trace
> below.
> Don't know if it's related but there is no binary ftp client on the machine.
> Issuing the same command on a windows machine deploys succesfully.
> [INFO] [deploy:deploy]
> [INFO] Retrieving previous build number from tux3-ftp-repository
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.wagon.providers.ftp.FtpWagon.openConnection(FtpWagon.java:127)
> at
> org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:354)
> at
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:295)
> at
> org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:356)
> at
> org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:310)
> at
> org.apache.maven.artifact.transform.SnapshotTransformation.resolveLatestSnapshotBuildNumber(SnapshotTransformation.java:158)
> at
> org.apache.maven.artifact.transform.SnapshotTransformation.transformForDeployment(SnapshotTransformation.java:97)
> at
> org.apache.maven.artifact.transform.DefaultArtifactTransformationManager.transformForDeployment(DefaultArtifactTransformationManager.java:61)
> at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:68)
> at
> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:131)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> 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:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> [INFO] Total time: 1 minute 5 seconds
> [INFO] Finished at: Fri Feb 17 17:26:57 CET 2006
> [INFO] Final Memory: 6M/25M
> [INFO]
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact o
[jira] Commented: (ARCHETYPE-33) Better Archetype template processing support
[ http://jira.codehaus.org/browse/ARCHETYPE-33?page=comments#action_70521 ]
Andrew Perepelytsya commented on ARCHETYPE-33:
--
This contribution is exactly what I was struggling for a while. The current m2
templating mechanism is weak, as it targets poms mostly, not project artifacts.
This new template worked well for me. The following 2 minor notes (which do not
affect the contribution code, however):
* JBI component artifact's pom declares a dependency on the parent (one of
bobber ones). This is not required to run the sample, just comment it out.
* There are minor typos in {{jbi.xml}} Velocity template (jbi.vm), namely
missing dot after a package placeholder, slash in a package name (while others
are dots). This is just a template tweak, so if anyone tries this, that's not
the fault of the plugin, but just a simple VM file :)
I would really love this one to be put eventually under standard maven-plugins
groupId so there's no need to fully qualify the archetype name. And, if
possible, target the inclusion for Maven 2.0.5 :)
> Better Archetype template processing support
>
>
> Key: ARCHETYPE-33
> URL: http://jira.codehaus.org/browse/ARCHETYPE-33
> Project: Maven Archetype
> Issue Type: Improvement
>Reporter: Aaron Anderson
> Assigned To: Jason van Zyl
>Priority: Trivial
> Attachments: new-archetype.zip
>
>
> I really love the maven 2 archetype concept and have developed an enhanced
> version that utilizes the velocity templating engine to a greater degree.
> While the code is fully functionality it needs to be cleaned up and the
> documentation enhanced. Please feel to incorporate any part of this back into
> maven 2 if any of it is appealing. If desired I could also enhance the code
> to make it a better contribution as well.
> To test out the archetype functionallity, run mvn install in both archetype
> (new plugin) and jbi-component (sample archetype)
> to execute the new archetype, run
> C:\temp\maventest> mvn
> com.javaforge.bobber:bobber-archetype:1.0-SNAPSHOT:create
> -DarchetypeGroupId=com.javaforge.bobber
> -DarchetypeArtifactId=maven-archetype-jbi-component
> -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=com.newarchetype -DartifactId=test
> in the same way the default archeype functionality works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2461) Write JavaDoc documentation
Write JavaDoc documentation --- Key: MNG-2461 URL: http://jira.codehaus.org/browse/MNG-2461 Project: Maven 2 Issue Type: Task Components: Documentation: General Affects Versions: 2.0.4 Reporter: Simon Kepp Nielsen Priority: Critical There hardly exists any JavaDoc documentation for Maven 2. Even very central classes such as Mojo, AbstractMojo, MavenProject, MavenProjectHelper and Artifact are completely undocumented. This makes it very difficult to write your own plugins, which seriously limits adoption of Maven 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVEN-1700) Maven 1.1 doesn't seems to set up appropriately the java.endored.dir property for Java under Mac OS X
[ http://jira.codehaus.org/browse/MAVEN-1700?page=comments#action_70525 ] Dain Sundstrom commented on MAVEN-1700: --- This does not fix the java.lang.NullPointerException at org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter.formatOutput(XMLJUnitResultFormatter.java:253) on OSX. The only way to have maven work property on OSX seems to be changing the /System/Library/Frameworks/JavaVM.framework/Versions/Current symlink. > Maven 1.1 doesn't seems to set up appropriately the java.endored.dir property > for Java under Mac OS X > - > > Key: MAVEN-1700 > URL: http://jira.codehaus.org/browse/MAVEN-1700 > Project: Maven > Issue Type: Bug > Components: cli >Affects Versions: 1.1-beta-1 > Environment: Mac OS X 10.4 - Java 1.4.2 - Should apply to any Mac OS > X and Java >Reporter: Ludovic Maître >Priority: Minor > > I had to add the following to the Maven 1.1b1 startup script for it to run > properly under Mac OS X : > if $darwin; then > MAVEN_OPTS="$MAVEN_OPTS > -Djava.endorsed.dirs=/System/Library/Java/Extensions" > fi > Because the extension are placed in this folder under Mac OS X Java > installation. However this as perhaps been already fixed. (also one should > have the Xerces libs in the above mentionned folder for running Maven 1.1b1 > with jdk 1.4.2 [the classes of Xerces are included in Java 1.5 AFAIK]). -- 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-1010) new testng 5.0 release
new testng 5.0 release -- Key: MAVENUPLOAD-1010 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1010 Project: maven-upload-requests Issue Type: Task Reporter: Jesse Kuhnert Attachments: testng-5.0-jdk14-bundle.jar, testng-5.0-jdk15-bundle.jar This is another "off the cuff" pom bundling that I may have screwed up. If someone knows a better way to do it I'm all for it. Brett knows how to reach me on im/email, if he needs to do this manually and it requires a change or something that I can do to make it easier let me know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2242) mvn command gives a Null Pointer Exception when a plugin is invalid
[ http://jira.codehaus.org/browse/MNG-2242?page=comments#action_70530 ] Todd Nine commented on MNG-2242: I am also receiving this error on a Maven1 plugin. However it has been wrapped with a Maven 2 POM, and it will run at the command line. For instance, if I execute the following command, the plugin runs successfully. mvn clean antlr:generate -Dgrammars=com/ata/util/validator/validwhen/ValidWhenParser.g However if I set up the following plugin maven maven-antlr-plugin 1.2.1 generate generate-sources com/ata/util/validator/validwhen/ValidWhenParser.g I receive a NullPointerException. If I can run the task from the command line, why can't I execute it as a plugin? I would really prefer to have this generated automatically before my compile task runs. Thanks, Todd Todd > mvn command gives a Null Pointer Exception when a plugin is invalid > --- > > Key: MNG-2242 > URL: http://jira.codehaus.org/browse/MNG-2242 > Project: Maven 2 > Issue Type: Bug > Environment: Windows XP, Mavne 2.0.2 >Reporter: Kin Leung > Fix For: 2.1 > > Attachments: pom.xml > > > I tried to use xdoclet with Maven 2.0.2 by adding those lines in pom.xml: > > bookstore-web > > > xdoclet > maven-xdoclet-plugin > 1.2 > > > generate-deployment-decriptor > generate-sources > > > > > >web.xml >src/main/webapp/WEB-INF > > > > webdoclet > > > > > > After I saved the file and run mvn (mvn install and mvn clean), it gives me > Null Pointer Exception: > Downloading: > http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave > n-xdoclet-plugin-1.2.pom > 159b downloaded > Downloading: > http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave > n-xdoclet-plugin-1.2.jar > 34K downloaded > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] null > [INFO] > - > --- > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM > anager.java:295) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De > faultPluginManager.java:200) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug > inManager.java:165) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa > ultLifecycleExecutor.java:1218) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifec > ycle(DefaultLifecycleExecutor.java:1182) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl > eMappings(DefaultLifecycleExecutor.java:950) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:450) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:139) > 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:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Meth
[jira] Created: (MANTLR-7) Cannot execute the plugin automatically in a pom
Cannot execute the plugin automatically in a pom Key: MANTLR-7 URL: http://jira.codehaus.org/browse/MANTLR-7 Project: Maven 2.x Antlr Plugin Issue Type: Bug Environment: Windows 2000 JDK 1.4 Reporter: Todd Nine I cannot execute the plugin automatically. Maven 2 configuration maven maven-antlr-plugin 1.2.1 generate generate-sources com/ata/util/validator/validwhen/ValidWhenParser.g C:\appdev\proj\partnership\partnershipBusiness>mvn -e clean compile + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] - --- [INFO] Building Partnership Business Logic [INFO]task-segment: [clean, compile] [INFO] - --- [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1216) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:982) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) 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:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon Jul 24 14:19:41 EDT 2006 [INFO] Final Memory: 1M/3M [INFO] -- 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-1700) Maven 1.1 doesn't seems to set up appropriately the java.endored.dir property for Java under Mac OS X
[ http://jira.codehaus.org/browse/MAVEN-1700?page=all ] Lukas Theussl closed MAVEN-1700. Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.1-beta-3 Added /System/Library/Java/Extensions to MAVEN_ENDORSED. The above comments are different issues. > Maven 1.1 doesn't seems to set up appropriately the java.endored.dir property > for Java under Mac OS X > - > > Key: MAVEN-1700 > URL: http://jira.codehaus.org/browse/MAVEN-1700 > Project: Maven > Issue Type: Bug > Components: cli >Affects Versions: 1.1-beta-1 > Environment: Mac OS X 10.4 - Java 1.4.2 - Should apply to any Mac OS > X and Java >Reporter: Ludovic Maître > Assigned To: Lukas Theussl >Priority: Minor > Fix For: 1.1-beta-3 > > > I had to add the following to the Maven 1.1b1 startup script for it to run > properly under Mac OS X : > if $darwin; then > MAVEN_OPTS="$MAVEN_OPTS > -Djava.endorsed.dirs=/System/Library/Java/Extensions" > fi > Because the extension are placed in this folder under Mac OS X Java > installation. However this as perhaps been already fixed. (also one should > have the Xerces libs in the above mentionned folder for running Maven 1.1b1 > with jdk 1.4.2 [the classes of Xerces are included in Java 1.5 AFAIK]). -- 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: (MPTEST-67) maven.compile.target is not considered in test:compile
maven.compile.target is not considered in test:compile -- Key: MPTEST-67 URL: http://jira.codehaus.org/browse/MPTEST-67 Project: maven-test-plugin Issue Type: Bug Affects Versions: 1.8 Reporter: Shinobu Kawai Priority: Blocker Attachments: MPTEST-67 Since maven.compile.target is not used to compile, forking with a lower version JVM does not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPTEST-67) maven.compile.target is not considered in test:compile
[ http://jira.codehaus.org/browse/MPTEST-67?page=all ] Shinobu Kawai updated MPTEST-67: Attachment: MPTEST-67 Patch to use maven.compile.target > maven.compile.target is not considered in test:compile > -- > > Key: MPTEST-67 > URL: http://jira.codehaus.org/browse/MPTEST-67 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: Shinobu Kawai >Priority: Blocker > Attachments: MPTEST-67 > > > Since maven.compile.target is not used to compile, forking with a lower > version JVM does not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPFAQ-20) Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3
Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3 Key: MPFAQ-20 URL: http://jira.codehaus.org/browse/MPFAQ-20 Project: maven-faq-plugin Issue Type: Bug Reporter: Lukas Theussl Assigned To: Lukas Theussl Fix For: 1.6.1 After our various dependency upgrades (jelly, dom4j, jaxen, xerces...), the faq plugin 1.6 does not process fml files correctly if they contain more than one section. Not sure what exactly causes it, but it gets fixed by using a 'var' parameter in the x:forEach loop over different parts. -- 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-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=comments#action_70536 ] Daniel Gredler commented on MNG-671: The Apache Tapestry project could use this feature... would outside help speed its development, or do we just need to wait? > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1 > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- 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: (MPFAQ-20) Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3
[ http://jira.codehaus.org/browse/MPFAQ-20?page=all ] Lukas Theussl closed MPFAQ-20. -- Resolution: Fixed > Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3 > > > Key: MPFAQ-20 > URL: http://jira.codehaus.org/browse/MPFAQ-20 > Project: maven-faq-plugin > Issue Type: Bug >Reporter: Lukas Theussl > Assigned To: Lukas Theussl > Fix For: 1.6.1 > > > After our various dependency upgrades (jelly, dom4j, jaxen, xerces...), the > faq plugin 1.6 does not process fml files correctly if they contain more than > one section. Not sure what exactly causes it, but it gets fixed by > using a 'var' parameter in the x:forEach loop over different parts. -- 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: (MPTEST-67) maven.compile.target is not considered in test:compile
[ http://jira.codehaus.org/browse/MPTEST-67?page=all ] Lukas Theussl closed MPTEST-67. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.8.1 Applied. Thanks! > maven.compile.target is not considered in test:compile > -- > > Key: MPTEST-67 > URL: http://jira.codehaus.org/browse/MPTEST-67 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: Shinobu Kawai > Assigned To: Lukas Theussl >Priority: Blocker > Fix For: 1.8.1 > > Attachments: MPTEST-67 > > > Since maven.compile.target is not used to compile, forking with a lower > version JVM does not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-33) add option to include modules in EAR in exploded (i.e. directory) form, rather than as in jar form
add option to include modules in EAR in exploded (i.e. directory) form, rather than as in jar form -- Key: MEAR-33 URL: http://jira.codehaus.org/browse/MEAR-33 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Ian Springer In JBoss, and perhaps other app servers, modules can be packaged in an EAR as directories. For example: my.ear/ my.war/ service1.sar/ service2.sar/ Please add an option on the ear plugin that allows you to specify that modules should be packaged in exploded 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] Created: (MAVENUPLOAD-1011) modified version of dtdparser for DTDDoc (upload request to follow)
modified version of dtdparser for DTDDoc (upload request to follow) --- Key: MAVENUPLOAD-1011 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1011 Project: maven-upload-requests Issue Type: Task Reporter: Hervé BOUTEMY Attachments: dtdparser.jar DTDDoc uses dtdparser, but some modifications have been made to support different encodings in DTDs -- 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-1012) DTDDoc is a DTD documentation tool a la javadoc
DTDDoc is a DTD documentation tool a la javadoc --- Key: MAVENUPLOAD-1012 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1012 Project: maven-upload-requests Issue Type: Task Reporter: Hervé BOUTEMY Attachments: DTDDoc.jar DTDDoc is a DTD documentation tool a la javadoc -- 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: (MPFAQ-20) Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3
[ http://jira.codehaus.org/browse/MPFAQ-20?page=comments#action_70540 ] Arnaud Heritier commented on MPFAQ-20: -- I found the following usages of x:forEach without a var attribute : plugins\changes\src\plugin-resources\changes.jsl(37): plugins\changes\src\plugin-resources\changes.jsl(55): plugins\changes\target\classes\plugin-resources\changes2rss.jsl(55): plugins\checkstyle\src\plugin-resources\checkstyle-summary.jsl(32): plugins\checkstyle\src\plugin-resources\checkstyle.jsl(86): plugins\checkstyle\src\plugin-resources\checkstyle.jsl(101): plugins\checkstyle\src\plugin-resources\checkstyle.jsl(116): plugins\jellydoc\src\plugin-resources\maven-jellydoc-plugin.jelly(89): plugins\jellydoc\src\plugin-resources\maven-jellydoc-plugin.jelly(101): plugins\jellydoc\src\plugin-resources\maven-jellydoc-plugin.jelly(116): plugins\jellydoc\src\plugin-resources\maven-jellydoc-plugin.jelly(141): plugins\jellydoc\src\plugin-resources\maven-jellydoc-plugin.jelly(143): Do you think that we have to fix them ? All others x:forEach have this attribute. And I found in several plugins the comment : > Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3 > > > Key: MPFAQ-20 > URL: http://jira.codehaus.org/browse/MPFAQ-20 > Project: maven-faq-plugin > Issue Type: Bug >Reporter: Lukas Theussl > Assigned To: Lukas Theussl > Fix For: 1.6.1 > > > After our various dependency upgrades (jelly, dom4j, jaxen, xerces...), the > faq plugin 1.6 does not process fml files correctly if they contain more than > one section. Not sure what exactly causes it, but it gets fixed by > using a 'var' parameter in the x:forEach loop over different parts. -- 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-126) Using Maven 1.x Legacy Repository Layout in a Maven 2.0.4 Project, I can't depend on a "java-sources" jar
Using Maven 1.x Legacy Repository Layout in a Maven 2.0.4 Project, I can't depend on a "java-sources" jar - Key: MRM-126 URL: http://jira.codehaus.org/browse/MRM-126 Project: Maven Repository Manager Issue Type: Bug Components: repository interface Environment: Mac Os X Reporter: Ed Burns Priority: Minor Consider this dependency: javax.faces jsf-api 1.2 sources This yields depdency id: javax.faces:jsf-api:jar:sources:1.2 This artifact is resolved from a 1.x Maven repository java.net Java.net Maven 1.x Repository for external projects https://maven-repository.dev.java.net/nonav/repository/ legacy And the path to the actual jar is https://maven-repository.dev.java.net/nonav/repository/javax.faces/java-sources/jsf-api-1.2-sources.jar However, maven 2.0.4 is trying to fetch: https://maven-repository.dev.java.net/nonav/repository/javax.faces/jars/jsf-api-1.2-sources.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: (MANTLR-7) Cannot execute the plugin automatically in a pom
[ http://jira.codehaus.org/browse/MANTLR-7?page=all ] Dennis Lundberg closed MANTLR-7. Resolution: Won't Fix That is because you are trying to use a Maven 1 plugin in Maven 2. You need to change a couple of lines in your pom to use the Maven 2 version: org.apache.maven.plugins maven-antlr-plugin 2.0-beta-1 > Cannot execute the plugin automatically in a pom > > > Key: MANTLR-7 > URL: http://jira.codehaus.org/browse/MANTLR-7 > Project: Maven 2.x Antlr Plugin > Issue Type: Bug > Environment: Windows 2000 JDK 1.4 >Reporter: Todd Nine > > I cannot execute the plugin automatically. > Maven 2 configuration > > > > maven > maven-antlr-plugin > 1.2.1 > > > > generate > > generate-sources > > > > > com/ata/util/validator/validwhen/ValidWhenParser.g > > > > > C:\appdev\proj\partnership\partnershipBusiness>mvn -e clean compile > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] > - > --- > [INFO] Building Partnership Business Logic > [INFO]task-segment: [clean, compile] > [INFO] > - > --- > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:292) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1252) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1216) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:982) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) > 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:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Mon Jul 24 14:19:41 EDT 2006 > [INFO] Final Memory: 1M/3M > [INFO] > -- 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-2242) mvn command gives a Null Pointer Exception when a plugin is invalid
[ http://jira.codehaus.org/browse/MNG-2242?page=comments#action_70543 ] Dennis Lundberg commented on MNG-2242: -- The command line and pom configuration that you have presented are not equal. You can read more on why here: http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html > mvn command gives a Null Pointer Exception when a plugin is invalid > --- > > Key: MNG-2242 > URL: http://jira.codehaus.org/browse/MNG-2242 > Project: Maven 2 > Issue Type: Bug > Environment: Windows XP, Mavne 2.0.2 >Reporter: Kin Leung > Fix For: 2.1 > > Attachments: pom.xml > > > I tried to use xdoclet with Maven 2.0.2 by adding those lines in pom.xml: > > bookstore-web > > > xdoclet > maven-xdoclet-plugin > 1.2 > > > generate-deployment-decriptor > generate-sources > > > > > >web.xml >src/main/webapp/WEB-INF > > > > webdoclet > > > > > > After I saved the file and run mvn (mvn install and mvn clean), it gives me > Null Pointer Exception: > Downloading: > http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave > n-xdoclet-plugin-1.2.pom > 159b downloaded > Downloading: > http://repo1.maven.org/maven2/xdoclet/maven-xdoclet-plugin/1.2/mave > n-xdoclet-plugin-1.2.jar > 34K downloaded > [INFO] > - > --- > [ERROR] FATAL ERROR > [INFO] > - > --- > [INFO] null > [INFO] > - > --- > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM > anager.java:295) > at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De > faultPluginManager.java:200) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug > inManager.java:165) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa > ultLifecycleExecutor.java:1218) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifec > ycle(DefaultLifecycleExecutor.java:1182) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl > eMappings(DefaultLifecycleExecutor.java:950) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:450) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:139) > 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:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.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) > [INFO] > - > --- > Looks like something is screwed up when maven attempts to run the plugin for > generating the web.xml of my servlet. I didn't do anything on the > settings.xml, does that matter? > Also the documentation is por and in worse case the poor documentation > offsets the benefits of the tool. -- 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: (MPFAQ-20) Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3
[ http://jira.codehaus.org/browse/MPFAQ-20?page=comments#action_70542 ] Lukas Theussl commented on MPFAQ-20: Yes, I'm aware of that. But AFAICT, the faq plugin is the only one where this leads to problems. I'm not sure about the cause, maybe it's because there is a nested forEach here, or because in all other cases, there is only one iteration. I have checked all the plugins above and haven't found a similar problem. No guarantees though... > Faq plugin 1.6 does not work with upgraded dependencies for Maven-1.1-beta-3 > > > Key: MPFAQ-20 > URL: http://jira.codehaus.org/browse/MPFAQ-20 > Project: maven-faq-plugin > Issue Type: Bug >Reporter: Lukas Theussl > Assigned To: Lukas Theussl > Fix For: 1.6.1 > > > After our various dependency upgrades (jelly, dom4j, jaxen, xerces...), the > faq plugin 1.6 does not process fml files correctly if they contain more than > one section. Not sure what exactly causes it, but it gets fixed by > using a 'var' parameter in the x:forEach loop over different parts. -- 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: (MPTEST-66) 1.8 version introduces bug in other plugins
[ http://jira.codehaus.org/browse/MPTEST-66?page=all ] Lukas Theussl closed MPTEST-66. --- Assignee: Lukas Theussl Resolution: Won't Fix It seems more logical to fix this in the war plugin. There is a slight backwards compatibility problem, but it only affects the case when test.skip=true, which is not recommended anyway (certainly not in production builds!). > 1.8 version introduces bug in other plugins > --- > > Key: MPTEST-66 > URL: http://jira.codehaus.org/browse/MPTEST-66 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: nicolas de loof > Assigned To: Lukas Theussl > Attachments: MPTEST-66.patch > > > When maven-war-plugin is run with maven.test.skip=true, the sources are not > compiled. > Latest version of test-plugin has removed prereqs on java:compile & > java:jar-resources. > Assuming other plugins themself run the java:compile goal may have impact on > lots of plugin and can break many application builds. I think the "test:test" > goal may have a prereqs="java:compile,java:jar-resources", and the > "test:compile" goal only prereqs="test:prepare-filesystem,test:test-resources" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPWAR-62) maven-war-plugin doesn't compile java sources when used with maven-test-plugin 1.8
[ http://jira.codehaus.org/browse/MPWAR-62?page=all ] Lukas Theussl closed MPWAR-62. -- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.6.3 Checking for maven.test.skip in the war plugin, so java:compile is not attained twice. Thanks! > maven-war-plugin doesn't compile java sources when used with > maven-test-plugin 1.8 > --- > > Key: MPWAR-62 > URL: http://jira.codehaus.org/browse/MPWAR-62 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: nicolas de loof > Assigned To: Lukas Theussl > Fix For: 1.6.3 > > Attachments: MPWAR-62.patch > > > I've found an issue when using latest versions of maven-test-plugin (1.8) : > when maven.test.skip=true is set, the goal is not executed. > This sounds good, BUT the maven-war-plugin use "test:test" goal to attain the > "java:compile" goal, so the generated war has no classes ! > The war:resources plugin should have > prereqs="war:war-resources,*java:compile*,test:test". -- 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] Moved: (MNG-2462) Using Maven 1.x Legacy Repository Layout in a Maven 2.0.4 Project, I can't depend on a "java-sources" jar
[ http://jira.codehaus.org/browse/MNG-2462?page=all ] John Casey moved MRM-126 to MNG-2462: - Component/s: (was: repository interface) Artifacts and Repositories Complexity: Intermediate Key: MNG-2462 (was: MRM-126) Project: Maven 2 (was: Maven Repository Manager) > Using Maven 1.x Legacy Repository Layout in a Maven 2.0.4 Project, I can't > depend on a "java-sources" jar > - > > Key: MNG-2462 > URL: http://jira.codehaus.org/browse/MNG-2462 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Mac Os X >Reporter: Ed Burns >Priority: Minor > Fix For: 2.0.5 > > > Consider this dependency: > > javax.faces > jsf-api > 1.2 > sources > > This yields depdency id: javax.faces:jsf-api:jar:sources:1.2 > This artifact is resolved from a 1.x Maven repository > > > java.net > Java.net Maven 1.x Repository for external projects > https://maven-repository.dev.java.net/nonav/repository/ > legacy > > And the path to the actual jar is > https://maven-repository.dev.java.net/nonav/repository/javax.faces/java-sources/jsf-api-1.2-sources.jar > However, maven 2.0.4 is trying to fetch: > https://maven-repository.dev.java.net/nonav/repository/javax.faces/jars/jsf-api-1.2-sources.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] Updated: (MNG-2462) Using Maven 1.x Legacy Repository Layout in a Maven 2.0.4 Project, I can't depend on a "java-sources" jar
[ http://jira.codehaus.org/browse/MNG-2462?page=all ] John Casey updated MNG-2462: Affects Version/s: 2.0.4 Fix Version/s: 2.0.5 > Using Maven 1.x Legacy Repository Layout in a Maven 2.0.4 Project, I can't > depend on a "java-sources" jar > - > > Key: MNG-2462 > URL: http://jira.codehaus.org/browse/MNG-2462 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Mac Os X >Reporter: Ed Burns >Priority: Minor > Fix For: 2.0.5 > > > Consider this dependency: > > javax.faces > jsf-api > 1.2 > sources > > This yields depdency id: javax.faces:jsf-api:jar:sources:1.2 > This artifact is resolved from a 1.x Maven repository > > > java.net > Java.net Maven 1.x Repository for external projects > https://maven-repository.dev.java.net/nonav/repository/ > legacy > > And the path to the actual jar is > https://maven-repository.dev.java.net/nonav/repository/javax.faces/java-sources/jsf-api-1.2-sources.jar > However, maven 2.0.4 is trying to fetch: > https://maven-repository.dev.java.net/nonav/repository/javax.faces/jars/jsf-api-1.2-sources.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] Updated: (MAVEN-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 & 2
[ http://jira.codehaus.org/browse/MAVEN-1755?page=all ] Lukas Theussl updated MAVEN-1755: - Priority: Critical (was: Major) Fix Version/s: (was: 1.1-beta-3) Need more time to check woodstox. > Backward Incompability : Usage of xml entities in the POM doesn't work in > maven 1.1 beta 1 & 2 > -- > > Key: MAVEN-1755 > URL: http://jira.codehaus.org/browse/MAVEN-1755 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-2, 1.1-beta-1 >Reporter: Arnaud Heritier >Priority: Critical > Attachments: project-entities.zip > > > In maven 1.0.X it was possible to use entities in the POM. > It was used for example to share some elements like the organization, ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVEN-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 & 2
[ http://jira.codehaus.org/browse/MAVEN-1755?page=comments#action_70546 ] Arnaud Heritier commented on MAVEN-1755: We have to modify modello (and not plexus) to use woodstox > Backward Incompability : Usage of xml entities in the POM doesn't work in > maven 1.1 beta 1 & 2 > -- > > Key: MAVEN-1755 > URL: http://jira.codehaus.org/browse/MAVEN-1755 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-2, 1.1-beta-1 >Reporter: Arnaud Heritier > Attachments: project-entities.zip > > > In maven 1.0.X it was possible to use entities in the POM. > It was used for example to share some elements like the organization, ... -- 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-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 & 2
[ http://jira.codehaus.org/browse/MAVEN-1755?page=all ] Lukas Theussl updated MAVEN-1755: - Affects Version/s: 1.1-beta-3 > Backward Incompability : Usage of xml entities in the POM doesn't work in > maven 1.1 beta 1 & 2 > -- > > Key: MAVEN-1755 > URL: http://jira.codehaus.org/browse/MAVEN-1755 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-2, 1.1-beta-1, 1.1-beta-3 >Reporter: Arnaud Heritier >Priority: Critical > Attachments: project-entities.zip > > > In maven 1.0.X it was possible to use entities in the POM. > It was used for example to share some elements like the organization, ... -- 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: (MPTEST-68) SourceModifications sometimes does not work for test classes
SourceModifications sometimes does not work for test classes
Key: MPTEST-68
URL: http://jira.codehaus.org/browse/MPTEST-68
Project: maven-test-plugin
Issue Type: Bug
Affects Versions: 1.6.2
Environment: Win XP, Maven 1.0.2
Reporter: Dennis Lundberg
Attachments: maven-test-plugin-sourceModifications.zip
First off run:
maven -X test
Then look at the "[javac] [DEBUG] fileset:" entry for test:compile. Mine looks
like this:
[javac] [DEBUG] fileset: Setup scanner in dir
G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
includes: [org/apache/commons/logging/*.java,
org/apache/commons/logging/impl/LogFactoryImpl.java,
org/apache/commons/logging/impl/WeakHashtable.java,
org/apache/commons/logging/impl/SimpleLog.java,
org/apache/commons/logging/impl/NoOpLog.java,
org/apache/commons/logging/impl/Jdk14Logger.java,
test/org/apache/commons/logging/SimpleLogTestCase.java] excludes:
[test/org/apache/commons/logging/servlet/*TestCase.java, **/package.html] }
Now go to the pom and remove the comments as specified in there. Run it again:
maven -X clean test
This time the build fails. Look at the fileset again. Mine looks like this:
[javac] [DEBUG] fileset: Setup scanner in dir
G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
includes: [] excludes: [**/package.html] }
Now that is the default values. What has happend here is that the section that
was un-commented from the pom will cause the property called "classPresent" to
be set during java:compile. That property can not be unset using ant. Because
the java-plugin and test-plugin uses the same property-name, it is highjacked
and test:compile will fail because of it.
I fiddled around in the test-plugin and managed to solve this problem. Will
attach patch shortly.
--
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-68) SourceModifications sometimes does not work for test classes
[ http://jira.codehaus.org/browse/MPTEST-68?page=all ]
Dennis Lundberg updated MPTEST-68:
--
Attachment: MPTEST-68.patch
By using another name for the property than maven-java-plugin does, the effects
of this issue is minimized.
> SourceModifications sometimes does not work for test classes
>
>
> Key: MPTEST-68
> URL: http://jira.codehaus.org/browse/MPTEST-68
> Project: maven-test-plugin
> Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: Win XP, Maven 1.0.2
>Reporter: Dennis Lundberg
> Attachments: maven-test-plugin-sourceModifications.zip,
> MPTEST-68.patch
>
>
> First off run:
> maven -X test
> Then look at the "[javac] [DEBUG] fileset:" entry for test:compile. Mine
> looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [org/apache/commons/logging/*.java,
> org/apache/commons/logging/impl/LogFactoryImpl.java,
> org/apache/commons/logging/impl/WeakHashtable.java,
> org/apache/commons/logging/impl/SimpleLog.java,
> org/apache/commons/logging/impl/NoOpLog.java,
> org/apache/commons/logging/impl/Jdk14Logger.java,
> test/org/apache/commons/logging/SimpleLogTestCase.java] excludes:
> [test/org/apache/commons/logging/servlet/*TestCase.java, **/package.html] }
> Now go to the pom and remove the comments as specified in there. Run it again:
> maven -X clean test
> This time the build fails. Look at the fileset again. Mine looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [] excludes: [**/package.html] }
> Now that is the default values. What has happend here is that the section
> that was un-commented from the pom will cause the property called
> "classPresent" to be set during java:compile. That property can not be unset
> using ant. Because the java-plugin and test-plugin uses the same
> property-name, it is highjacked and test:compile will fail because of it.
> I fiddled around in the test-plugin and managed to solve this problem. Will
> attach patch shortly.
--
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: (MEAR-33) add option to include modules in EAR in exploded (i.e. directory) form, rather than as in jar form
[ http://jira.codehaus.org/browse/MEAR-33?page=all ] Ian Springer updated MEAR-33: - Attachment: MEAR-33.patch Here's a patch that implements the requested feature. > add option to include modules in EAR in exploded (i.e. directory) form, > rather than as in jar form > -- > > Key: MEAR-33 > URL: http://jira.codehaus.org/browse/MEAR-33 > Project: Maven 2.x Ear Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ian Springer > Attachments: MEAR-33.patch > > > In JBoss, and perhaps other app servers, modules can be packaged in an EAR as > directories. For example: > my.ear/ > my.war/ > service1.sar/ > service2.sar/ > Please add an option on the ear plugin that allows you to specify that > modules should be packaged in exploded 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: (MPTEST-68) SourceModifications sometimes does not work for test classes
[ http://jira.codehaus.org/browse/MPTEST-68?page=comments#action_70552 ]
Dennis Lundberg commented on MPTEST-68:
---
Oh, I forgot: the patch is against SVN head.
> SourceModifications sometimes does not work for test classes
>
>
> Key: MPTEST-68
> URL: http://jira.codehaus.org/browse/MPTEST-68
> Project: maven-test-plugin
> Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: Win XP, Maven 1.0.2
>Reporter: Dennis Lundberg
> Attachments: maven-test-plugin-sourceModifications.zip,
> MPTEST-68.patch
>
>
> First off run:
> maven -X test
> Then look at the "[javac] [DEBUG] fileset:" entry for test:compile. Mine
> looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [org/apache/commons/logging/*.java,
> org/apache/commons/logging/impl/LogFactoryImpl.java,
> org/apache/commons/logging/impl/WeakHashtable.java,
> org/apache/commons/logging/impl/SimpleLog.java,
> org/apache/commons/logging/impl/NoOpLog.java,
> org/apache/commons/logging/impl/Jdk14Logger.java,
> test/org/apache/commons/logging/SimpleLogTestCase.java] excludes:
> [test/org/apache/commons/logging/servlet/*TestCase.java, **/package.html] }
> Now go to the pom and remove the comments as specified in there. Run it again:
> maven -X clean test
> This time the build fails. Look at the fileset again. Mine looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [] excludes: [**/package.html] }
> Now that is the default values. What has happend here is that the section
> that was un-commented from the pom will cause the property called
> "classPresent" to be set during java:compile. That property can not be unset
> using ant. Because the java-plugin and test-plugin uses the same
> property-name, it is highjacked and test:compile will fail because of it.
> I fiddled around in the test-plugin and managed to solve this problem. Will
> attach patch shortly.
--
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: (MPTEST-68) SourceModifications sometimes does not work for test classes
[ http://jira.codehaus.org/browse/MPTEST-68?page=all ]
Lukas Theussl closed MPTEST-68.
---
Assignee: Lukas Theussl
Resolution: Fixed
Fix Version/s: 1.8.1
Patch applied. Thanks!
> SourceModifications sometimes does not work for test classes
>
>
> Key: MPTEST-68
> URL: http://jira.codehaus.org/browse/MPTEST-68
> Project: maven-test-plugin
> Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: Win XP, Maven 1.0.2
>Reporter: Dennis Lundberg
> Assigned To: Lukas Theussl
> Fix For: 1.8.1
>
> Attachments: maven-test-plugin-sourceModifications.zip,
> MPTEST-68.patch
>
>
> First off run:
> maven -X test
> Then look at the "[javac] [DEBUG] fileset:" entry for test:compile. Mine
> looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [org/apache/commons/logging/*.java,
> org/apache/commons/logging/impl/LogFactoryImpl.java,
> org/apache/commons/logging/impl/WeakHashtable.java,
> org/apache/commons/logging/impl/SimpleLog.java,
> org/apache/commons/logging/impl/NoOpLog.java,
> org/apache/commons/logging/impl/Jdk14Logger.java,
> test/org/apache/commons/logging/SimpleLogTestCase.java] excludes:
> [test/org/apache/commons/logging/servlet/*TestCase.java, **/package.html] }
> Now go to the pom and remove the comments as specified in there. Run it again:
> maven -X clean test
> This time the build fails. Look at the fileset again. Mine looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [] excludes: [**/package.html] }
> Now that is the default values. What has happend here is that the section
> that was un-commented from the pom will cause the property called
> "classPresent" to be set during java:compile. That property can not be unset
> using ant. Because the java-plugin and test-plugin uses the same
> property-name, it is highjacked and test:compile will fail because of it.
> I fiddled around in the test-plugin and managed to solve this problem. Will
> attach patch shortly.
--
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: (MPTEST-68) SourceModifications sometimes does not work for test classes
[ http://jira.codehaus.org/browse/MPTEST-68?page=comments#action_70558 ]
Lukas Theussl commented on MPTEST-68:
-
Wait a minute... why am I doing that? You are a maven committer! ;)
> SourceModifications sometimes does not work for test classes
>
>
> Key: MPTEST-68
> URL: http://jira.codehaus.org/browse/MPTEST-68
> Project: maven-test-plugin
> Issue Type: Bug
>Affects Versions: 1.6.2
> Environment: Win XP, Maven 1.0.2
>Reporter: Dennis Lundberg
> Assigned To: Lukas Theussl
> Fix For: 1.8.1
>
> Attachments: maven-test-plugin-sourceModifications.zip,
> MPTEST-68.patch
>
>
> First off run:
> maven -X test
> Then look at the "[javac] [DEBUG] fileset:" entry for test:compile. Mine
> looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [org/apache/commons/logging/*.java,
> org/apache/commons/logging/impl/LogFactoryImpl.java,
> org/apache/commons/logging/impl/WeakHashtable.java,
> org/apache/commons/logging/impl/SimpleLog.java,
> org/apache/commons/logging/impl/NoOpLog.java,
> org/apache/commons/logging/impl/Jdk14Logger.java,
> test/org/apache/commons/logging/SimpleLogTestCase.java] excludes:
> [test/org/apache/commons/logging/servlet/*TestCase.java, **/package.html] }
> Now go to the pom and remove the comments as specified in there. Run it again:
> maven -X clean test
> This time the build fails. Look at the fileset again. Mine looks like this:
> [javac] [DEBUG] fileset: Setup scanner in dir
> G:\test\maven-test-plugin-sourceModifications\src\test with patternSet{
> includes: [] excludes: [**/package.html] }
> Now that is the default values. What has happend here is that the section
> that was un-commented from the pom will cause the property called
> "classPresent" to be set during java:compile. That property can not be unset
> using ant. Because the java-plugin and test-plugin uses the same
> property-name, it is highjacked and test:compile will fail because of it.
> I fiddled around in the test-plugin and managed to solve this problem. Will
> attach patch shortly.
--
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-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=comments#action_70559 ] Brett Porter commented on MNG-671: -- outside help is always welcome :) > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1 > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSUREFIRE-150) 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException (regression)
2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException
(regression)
--
Key: MSUREFIRE-150
URL: http://jira.codehaus.org/browse/MSUREFIRE-150
Project: Maven 2.x Surefire Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Andrew Perepelytsya
Ok, I know how tricky it can be to explain such bug, but I'll try. We've
switched to using 2.3-SNAPSHOT version of the plugin to get the fix for this
error when test reports failed the build in case of test errors without
generating any report. This part works fine now, but it has introduced a
regression.
I'm attaching the test failure reports(it always worked before). To reproduce
the error (tricky part) - I can only think of checking out Mule project SVN
source as of r2315 from http://svn.codehaus.org/mule/ What you need is only a
top-level dir and mule-core.
{panel}
mvn test -Dtest=SerializedUMOMessageTransformersTestCase
{panel}
r2315 has 2.3-SNAPSHOT plugin version declared in a top-level pom. Change it to
RELEASE, and the problem is again gone.
I'm also attaching m2 debug output for SNAPSHOT and RELEASE runs, hope it helps.
--
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: (MSUREFIRE-150) 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException (regression)
[ http://jira.codehaus.org/browse/MSUREFIRE-150?page=all ]
Andrew Perepelytsya updated MSUREFIRE-150:
--
Attachment: RELEASE-m2-run.txt
TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt
> 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException
> (regression)
> --
>
> Key: MSUREFIRE-150
> URL: http://jira.codehaus.org/browse/MSUREFIRE-150
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrew Perepelytsya
> Attachments:
> org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
> RELEASE-m2-run.txt, SNAPSHOT-m2-run.txt,
> TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
>
>
> Ok, I know how tricky it can be to explain such bug, but I'll try. We've
> switched to using 2.3-SNAPSHOT version of the plugin to get the fix for this
> error when test reports failed the build in case of test errors without
> generating any report. This part works fine now, but it has introduced a
> regression.
> I'm attaching the test failure reports(it always worked before). To reproduce
> the error (tricky part) - I can only think of checking out Mule project SVN
> source as of r2315 from http://svn.codehaus.org/mule/ What you need is only a
> top-level dir and mule-core.
> {panel}
> mvn test -Dtest=SerializedUMOMessageTransformersTestCase
> {panel}
> r2315 has 2.3-SNAPSHOT plugin version declared in a top-level pom. Change it
> to RELEASE, and the problem is again gone.
> I'm also attaching m2 debug output for SNAPSHOT and RELEASE runs, hope it
> helps.
--
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: (MSUREFIRE-150) 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException (regression)
[ http://jira.codehaus.org/browse/MSUREFIRE-150?page=all ]
Andrew Perepelytsya updated MSUREFIRE-150:
--
Attachment: SNAPSHOT-m2-run.txt
> 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException
> (regression)
> --
>
> Key: MSUREFIRE-150
> URL: http://jira.codehaus.org/browse/MSUREFIRE-150
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrew Perepelytsya
> Attachments:
> org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
> RELEASE-m2-run.txt, SNAPSHOT-m2-run.txt,
> TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
>
>
> Ok, I know how tricky it can be to explain such bug, but I'll try. We've
> switched to using 2.3-SNAPSHOT version of the plugin to get the fix for this
> error when test reports failed the build in case of test errors without
> generating any report. This part works fine now, but it has introduced a
> regression.
> I'm attaching the test failure reports(it always worked before). To reproduce
> the error (tricky part) - I can only think of checking out Mule project SVN
> source as of r2315 from http://svn.codehaus.org/mule/ What you need is only a
> top-level dir and mule-core.
> {panel}
> mvn test -Dtest=SerializedUMOMessageTransformersTestCase
> {panel}
> r2315 has 2.3-SNAPSHOT plugin version declared in a top-level pom. Change it
> to RELEASE, and the problem is again gone.
> I'm also attaching m2 debug output for SNAPSHOT and RELEASE runs, hope it
> helps.
--
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: (MSUREFIRE-150) 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException (regression)
[ http://jira.codehaus.org/browse/MSUREFIRE-150?page=comments#action_70562
]
Andrew Perepelytsya commented on MSUREFIRE-150:
---
For your convenience: source code for the test case
http://svn.mule.codehaus.org/browse/mule/trunk/mule/mule/src/test/java/org/mule/test/transformers/SerializedUMOMessageTransformersTestCase.java?r=2176
> 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException
> (regression)
> --
>
> Key: MSUREFIRE-150
> URL: http://jira.codehaus.org/browse/MSUREFIRE-150
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrew Perepelytsya
> Attachments:
> org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
> RELEASE-m2-run.txt, SNAPSHOT-m2-run.txt,
> TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
>
>
> Ok, I know how tricky it can be to explain such bug, but I'll try. We've
> switched to using 2.3-SNAPSHOT version of the plugin to get the fix for this
> error when test reports failed the build in case of test errors without
> generating any report. This part works fine now, but it has introduced a
> regression.
> I'm attaching the test failure reports(it always worked before). To reproduce
> the error (tricky part) - I can only think of checking out Mule project SVN
> source as of r2315 from http://svn.codehaus.org/mule/ What you need is only a
> top-level dir and mule-core.
> {panel}
> mvn test -Dtest=SerializedUMOMessageTransformersTestCase
> {panel}
> r2315 has 2.3-SNAPSHOT plugin version declared in a top-level pom. Change it
> to RELEASE, and the problem is again gone.
> I'm also attaching m2 debug output for SNAPSHOT and RELEASE runs, hope it
> helps.
--
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: (MSUREFIRE-150) 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException (regression)
[ http://jira.codehaus.org/browse/MSUREFIRE-150?page=all ]
Andrew Perepelytsya updated MSUREFIRE-150:
--
Attachment:
FAILED_TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
FAILED_org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt
> 2.3-SNAPSHOT fails to deserialize an object due to ClassNotFoundException
> (regression)
> --
>
> Key: MSUREFIRE-150
> URL: http://jira.codehaus.org/browse/MSUREFIRE-150
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Andrew Perepelytsya
> Attachments:
> FAILED_org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
>
> FAILED_TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml,
> org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.txt,
> RELEASE-m2-run.txt, SNAPSHOT-m2-run.txt,
> TEST-org.mule.test.transformers.SerializedUMOMessageTransformersTestCase.xml
>
>
> Ok, I know how tricky it can be to explain such bug, but I'll try. We've
> switched to using 2.3-SNAPSHOT version of the plugin to get the fix for this
> error when test reports failed the build in case of test errors without
> generating any report. This part works fine now, but it has introduced a
> regression.
> I'm attaching the test failure reports(it always worked before). To reproduce
> the error (tricky part) - I can only think of checking out Mule project SVN
> source as of r2315 from http://svn.codehaus.org/mule/ What you need is only a
> top-level dir and mule-core.
> {panel}
> mvn test -Dtest=SerializedUMOMessageTransformersTestCase
> {panel}
> r2315 has 2.3-SNAPSHOT plugin version declared in a top-level pom. Change it
> to RELEASE, and the problem is again gone.
> I'm also attaching m2 debug output for SNAPSHOT and RELEASE runs, hope it
> helps.
--
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: (MCHANGES-49) javax.mail dependency should be optional
javax.mail dependency should be optional Key: MCHANGES-49 URL: http://jira.codehaus.org/browse/MCHANGES-49 Project: Maven 2.x Changes Plugin Issue Type: Improvement Affects Versions: 2.0-beta-2 Reporter: Wendy Smoak With maven-changes-plugin configured, I'm unable to generate the changes report for the website without installing Sun's mail and activation jars. -- 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-127) refactor and review indexing and search
refactor and review indexing and search --- Key: MRM-127 URL: http://jira.codehaus.org/browse/MRM-127 Project: Maven Repository Manager Issue Type: Bug Components: indexing Affects Versions: 1.0-beta-1 Reporter: Brett Porter Fix For: 1.0-beta-1 the indexing that is currently in place doesn't seem to be working well. - creating the metadata index erases all artifacts - the ms count for the initial index seems shorter than it takes - design improvements needed for search: - general search simply iterates all fields looking for keywords, which probably doesn't rank optimally - search fails on "maven" as it tries to load a metadata file that contains it incorrectly. It shouldn't need to read the metadata files of the search results. - general search doesn't appear to search metadata - design improvements needed -- 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-127) refactor and review indexing and search
[ http://jira.codehaus.org/browse/MRM-127?page=all ] Brett Porter updated MRM-127: - Assignee: Brett Porter Fix Version/s: 1.0-beta-1 Remaining Estimate: 6 hours Original Estimate: 6 hours > refactor and review indexing and search > --- > > Key: MRM-127 > URL: http://jira.codehaus.org/browse/MRM-127 > Project: Maven Repository Manager > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > the indexing that is currently in place doesn't seem to be working well. > - creating the metadata index erases all artifacts > - the ms count for the initial index seems shorter than it takes > - design improvements needed > for search: > - general search simply iterates all fields looking for keywords, which > probably doesn't rank optimally > - search fails on "maven" as it tries to load a metadata file that contains > it incorrectly. It shouldn't need to read the metadata files of the search > results. > - general search doesn't appear to search metadata > - design improvements needed -- 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: (MCHECKSTYLE-49) Review and revise plugin documentation
[ http://jira.codehaus.org/browse/MCHECKSTYLE-49?page=comments#action_70564 ] Maria Odea Ching commented on MCHECKSTYLE-49: - Review comments by Vincent Siveton (from Maven Dev List): -- here my comments: usage.html Should be better to create two subsections: - Generate the report as part of Project Reports - Generate the report as standalone Maybe add a report screenshot FAQ "checkstyle.properties" or "checkstyle properties" (with space) If the first, the following seems wrong according the doc checkstyle.properties http://people.apache.org/~oching/maven-checkstyle-plugin/checkstyle-mojo.html#configLocation custom-property-expansion.html propertiesLocation has no sample. Is is the same explained in FAQ? multi-module-config.html Review it as said Replace unix commands by a directory layout: whizbang |-- pom.xml `-- src |-- main ... Cheers, Vincent > Review and revise plugin documentation > -- > > Key: MCHECKSTYLE-49 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-49 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: documentation.patch > > Original Estimate: 22 hours > Time Spent: 22 hours > Remaining Estimate: 0 minutes > -- 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: (MCHECKSTYLE-49) Review and revise plugin documentation
[ http://jira.codehaus.org/browse/MCHECKSTYLE-49?page=comments#action_70565 ] Maria Odea Ching commented on MCHECKSTYLE-49: - Review comments by Stephen Duncan (from Maven Dev List): - On the "Multimodule Configuration" documentation: As I just mentioned on a question on the user's list, I don't think it's correct to specify the "build-tools" dependency as a dependency of the plugin. While this will work if you manually install the build-tools jar, it will not download it from an internal repository. It should instead be specified as build extension like in the "Using Custom Developed Chechstyle Check Modules" example. (Also not the spelling mistake in that title: ChecHstyle). Because this is somewhat confusing, I think it should mentioned either in the "Using a Custom Checkstyle Checker Configuration" as a way of using a classpath reference, or it should be it's own guide on using a shared jar for configuration. - Stephen > Review and revise plugin documentation > -- > > Key: MCHECKSTYLE-49 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-49 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: documentation.patch > > Original Estimate: 22 hours > Time Spent: 22 hours > Remaining Estimate: 0 minutes > -- 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: (MCHECKSTYLE-49) Review and revise plugin documentation
[ http://jira.codehaus.org/browse/MCHECKSTYLE-49?page=comments#action_70566 ] Maria Odea Ching commented on MCHECKSTYLE-49: - Review comments by Dennis Lundberg (from Maven Dev List): - +1 to put the it in a guide of its own. I believe that this is a very common thing that companies and large organizations want to do. I've attached a path to MCHECKSTYLE-49 with some minor fixes. The goal descriptions are not clear to me as they are now. What is the difference between the goals? It sound like they do the same thing. Also their descriptions are not the same on the index page as on the plugin-info page. > Review and revise plugin documentation > -- > > Key: MCHECKSTYLE-49 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-49 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: documentation.patch > > Original Estimate: 22 hours > Time Spent: 22 hours > Remaining Estimate: 0 minutes > -- 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: (MSUREFIREREP-24) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MSUREFIREREP-24?page=all ] Allan Ramirez closed MSUREFIREREP-24. - Resolution: Fixed Applied the docs review to svn. > Review Plugin Documentation > --- > > Key: MSUREFIREREP-24 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-24 > Project: Maven 2.x Surefire report Plugin > Issue Type: Task >Reporter: Allan Ramirez > Assigned To: Allan Ramirez > Original Estimate: 16 hours > Time Spent: 17 hours > Remaining Estimate: 0 minutes > -- 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-127) refactor and review indexing and search
[ http://jira.codehaus.org/browse/MRM-127?page=comments#action_70569 ] Milos Kleint commented on MRM-127: -- also please consider how the pom models ought to be stored. (and retrieved) - MRM-121 I noticed you did some changes that involved merging the pom and artifact index lately. However it's still using the MavenXpp3Reader to load the pom model. That gives incomplete info on 1. version+groupId in case you have a parent pom (you seemed to workaround it by setting the parent's version+groupId) 2. dependencies, plugin information is also incomplete 3. if any of the values are defined as property it will list them as such (not sure haven't tested) > refactor and review indexing and search > --- > > Key: MRM-127 > URL: http://jira.codehaus.org/browse/MRM-127 > Project: Maven Repository Manager > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > the indexing that is currently in place doesn't seem to be working well. > - creating the metadata index erases all artifacts > - the ms count for the initial index seems shorter than it takes > - design improvements needed > for search: > - general search simply iterates all fields looking for keywords, which > probably doesn't rank optimally > - search fails on "maven" as it tries to load a metadata file that contains > it incorrectly. It shouldn't need to read the metadata files of the search > results. > - general search doesn't appear to search metadata > - design improvements needed -- 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-127) refactor and review indexing and search
[ http://jira.codehaus.org/browse/MRM-127?page=comments#action_70570 ] Brett Porter commented on MRM-127: -- yes, I'd identified that problem too, so I'm continuing on - will definitely take that into account, thanks for the reminder. Sorry I missed your original patch. > refactor and review indexing and search > --- > > Key: MRM-127 > URL: http://jira.codehaus.org/browse/MRM-127 > Project: Maven Repository Manager > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > the indexing that is currently in place doesn't seem to be working well. > - creating the metadata index erases all artifacts > - the ms count for the initial index seems shorter than it takes > - design improvements needed > for search: > - general search simply iterates all fields looking for keywords, which > probably doesn't rank optimally > - search fails on "maven" as it tries to load a metadata file that contains > it incorrectly. It shouldn't need to read the metadata files of the search > results. > - general search doesn't appear to search metadata > - design improvements needed -- 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-127) refactor and review indexing and search
[ http://jira.codehaus.org/browse/MRM-127?page=comments#action_70571 ] Milos Kleint commented on MRM-127: -- one more thing that comes to mind. if we are to support the usecase where one downloads the index from a remote repository and works with it locally, then it's crucial that the searcher code works only on top of the index files and never contacts the remote repository (it used to do for poms I suppose where the pom was reparsed and returned from the SearchHit - not sure if it's still in the codebase) > refactor and review indexing and search > --- > > Key: MRM-127 > URL: http://jira.codehaus.org/browse/MRM-127 > Project: Maven Repository Manager > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > the indexing that is currently in place doesn't seem to be working well. > - creating the metadata index erases all artifacts > - the ms count for the initial index seems shorter than it takes > - design improvements needed > for search: > - general search simply iterates all fields looking for keywords, which > probably doesn't rank optimally > - search fails on "maven" as it tries to load a metadata file that contains > it incorrectly. It shouldn't need to read the metadata files of the search > results. > - general search doesn't appear to search metadata > - design improvements needed -- 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-127) refactor and review indexing and search
[ http://jira.codehaus.org/browse/MRM-127?page=comments#action_70572 ] Brett Porter commented on MRM-127: -- the searcher will not be reading from the repository, just the index. I've put a design doc in SVN - let me know if you think anything is missing > refactor and review indexing and search > --- > > Key: MRM-127 > URL: http://jira.codehaus.org/browse/MRM-127 > Project: Maven Repository Manager > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > the indexing that is currently in place doesn't seem to be working well. > - creating the metadata index erases all artifacts > - the ms count for the initial index seems shorter than it takes > - design improvements needed > for search: > - general search simply iterates all fields looking for keywords, which > probably doesn't rank optimally > - search fails on "maven" as it tries to load a metadata file that contains > it incorrectly. It shouldn't need to read the metadata files of the search > results. > - general search doesn't appear to search metadata > - design improvements needed -- 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
