[jira] Commented: (CONTINUUM-581) Share continuum build number to underlying build project
[ http://jira.codehaus.org/browse/CONTINUUM-581?page=comments#action_63283
]
Geoff Urbach commented on CONTINUUM-581:
In a similar way we would like to quote the build number (version) on the
"About" screen. It seems like a fundamental feature to me that I have becone
quite acustomed to with Cruise Control.
cheers,
g
> Share continuum build number to underlying build project
>
>
> Key: CONTINUUM-581
> URL: http://jira.codehaus.org/browse/CONTINUUM-581
> Project: Continuum
> Type: New Feature
> Reporter: Alex Boisvert
>
>
> It would be nice if Continuum shared its build number with the underlying
> build projects (e.g. Ant/Maven{1,2})
> What I'm trying to do is generate artifacts with the following naming
> convention:
> myproject-1.0-123.zip
> where 1.0 is the version number defined in Maven (e.g. pom.xml), and 123
> is the Continuum build number. Artifacts could be .zip, .jar, .war, etc.
> I guess one way to do this is to pass the build number via an environment
> variable
--
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-97) Allow providing custom target for eclipse use
Allow providing custom target for eclipse use - Key: MECLIPSE-97 URL: http://jira.codehaus.org/browse/MECLIPSE-97 Project: Maven 2.x Eclipse Plugin Type: Improvement Reporter: Jukka Lindström .project files created with eclipse:eclipse point to the same compliation target directory as maven (that is target/classes). However I would want eclipse to use different target directories than maven because maven clean will also trigger a eclipse build and this causes problems. -- 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-56) The "pertest" option for forking mode should be renamed more appropriately
[ http://jira.codehaus.org/browse/MSUREFIRE-56?page=comments#action_63285 ] Joerg Schaible commented on MSUREFIRE-56: - Backwards compatibility was already broken by renaming "perTest" to "pertest". > The "pertest" option for forking mode should be renamed more appropriately > -- > > Key: MSUREFIRE-56 > URL: http://jira.codehaus.org/browse/MSUREFIRE-56 > Project: Maven 2.x Surefire Plugin > Type: Improvement > Versions: 2.1.2 > Reporter: Jason van Zyl > Fix For: 2.2 > > > The option should be called "pertestcase" or "perbattery" or something akin. > Open to suggestions here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-61) Adding custom source paths to javadoc
[ http://jira.codehaus.org/browse/MJAVADOC-61?page=comments#action_63286 ]
Jukka Raanamo commented on MJAVADOC-61:
---
I ran into the same problem. To fix it, you'll need to insert javadoc plugin
into the build lifecycle at such point where any additional compile source
roots have already been added to the project.
E.g.:
org.apache.maven.plugins
maven-javadoc-plugin
process-sources
javadoc
maven-antrun-plugin
generate-sources
${project.build.directory}/generated/java
... some ant tasks
run
Here javadoc plugin is invoked after antrun plugin and therefore given
sourceRoot is added to projects compile source roots. This may not be the right
way to do it but that's how I got it working. Also notice that your code
generator must be run from a plugin that adds the compile source root into the
project like antrun does. Hope this is of any help.
> Adding custom source paths to javadoc
> -
>
> Key: MJAVADOC-61
> URL: http://jira.codehaus.org/browse/MJAVADOC-61
> Project: Maven 2.x Javadoc Plugin
> Type: New Feature
> Versions: 2.0-beta-3
> Environment: FedoreCore 4 kernel 2.6.10-1.760_FC3smp #1
> Reporter: Erik van Zijst
>
>
> I have a code generator that creates sources during the compile stage. These
> sources end up in a custom directory
> (${project.build.directory}/generated-sources/main/java). The problem is that
> javadoc skips these files when it generates the documentation. What I'm
> looking for is a way to manipulate javadoc's sourcefilenames argument.
> I have already tried adding
> ${project.build.directory}/generated-sources/main/java
> to the code generation step, but it didn't affect 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: (MNGECLIPSE-98) Allow automatic attaching of sources to the binary dependencies
[ http://jira.codehaus.org/browse/MNGECLIPSE-98?page=comments#action_63287 ] Dimitry Voytenko commented on MNGECLIPSE-98: thanks a lot. sorry for spam. > Allow automatic attaching of sources to the binary dependencies > --- > > Key: MNGECLIPSE-98 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-98 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.5 > Reporter: Dimitry Voytenko > Assignee: Eugene Kuleshov > > > For the automatic dependencies resolution to work, it should allow attaching > sources from the repository to the dependenciy binaries. -- 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: (SCM-183) Added listFiles to ScmProvider
[ http://jira.codehaus.org/browse/SCM-183?page=comments#action_63288 ] Emmanuel Venisse commented on SCM-183: -- Some files are missing in your patch like CvsExeListFilesCommand > Added listFiles to ScmProvider > -- > > Key: SCM-183 > URL: http://jira.codehaus.org/browse/SCM-183 > Project: Maven SCM > Type: New Feature > Components: maven-scm-api > Reporter: Zsolt Koppany > Attachments: scm-maven.patch, scm-maven.patch > > > This patch adds "listFiles" method to "ScmProvider" and contains the > implementation for subversion. -- 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-1755) Improve support for in reactor builds
[ http://jira.codehaus.org/browse/MNG-1755?page=comments#action_63291 ] Joerg Schaible commented on MNG-1755: - Was about to suggest the same or at least something similar: Despite Mike's developerManagement the teamManagement would contain developers and constributors. Nevertheless this would be a great addition for anyone using the Super POM model in a company. > Improve support for in reactor builds > -- > > Key: MNG-1755 > URL: http://jira.codehaus.org/browse/MNG-1755 > Project: Maven 2 > Type: Improvement > Components: POM > Reporter: Mike Perham > > > I would like to see something like added which acts > similarly to the other management elements in the POM. This would allow a > top-level project POM to list all the developers, their orgs, timezones, > emails, etc and child projects to reference just the ID and the developers > role in that module. Something like this: > parent's pom.xml: > > > msanchez > Matt Sanchez > [EMAIL PROTECTED] > http://priori.webify.local:9090/display/~msanchez > -6 > > > mperham > Mike Perham > [EMAIL PROTECTED] > http://priori:9090/display/~mperham > -6 > > > foo's pom.xml: > > > mperham > > Owner > > > > Our management wants to have one or two clear-cut owners for each module and > we would like to use maven to document those owners but the current impl is > terribly redundant since developers are not inherited. -- 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-2219) artifactId appended to URL in scm reports. Problem apparently comes from the core.
artifactId appended to URL in scm reports. Problem apparently comes from the core. -- Key: MNG-2219 URL: http://jira.codehaus.org/browse/MNG-2219 Project: Maven 2 Type: Bug Reporter: Jerome Lacoste See MPIR-42 for description of the issue. This issue is supposedly already reported but I wasn't able to find it. Feel free to duplicate it against the correct one. I have several users of the webstart plugin confused because the rendered scm information is incorrect. -- 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: (MCHANGELOG-17) changelog, file activity and developer activity reports are all identical (to the changelog report)
[ http://jira.codehaus.org/browse/MCHANGELOG-17?page=all ] Edwin Punzalan closed MCHANGELOG-17: Assign To: Edwin Punzalan Resolution: Duplicate > changelog, file activity and developer activity reports are all identical (to > the changelog report) > --- > > Key: MCHANGELOG-17 > URL: http://jira.codehaus.org/browse/MCHANGELOG-17 > Project: Maven 2.x Changelog Plugin > Type: Bug > Versions: 2.0 > Environment: osx 10.4.5, java 1.4.2_09 > Reporter: Julian Wood > Assignee: Edwin Punzalan > Fix For: 2.0 > > > Given this part of the pom, I get links to 3 reports in the site, but all are > just the changelog report in duplicate. I tested this before (and after) > applying the MCHANGELOG-16.patch, but after the MCHANGELOG-15.patch, which is > required to get the report to run without exceptions, so this would seem to > have something to do with the move from mojo to maven code trees. > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-beta-2-SNAPSHOT > > > changes > > > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&rev=0&sc=0&path= > range > 90 > > > changelog > file-activity > dev-activity > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGELOG-12) When generating a FileActivity or DevActivity report the report contents is ChangeLog report contents
[ http://jira.codehaus.org/browse/MCHANGELOG-12?page=all ]
Edwin Punzalan closed MCHANGELOG-12:
Assign To: Edwin Punzalan
Resolution: Fixed
Fixed in SVN
> When generating a FileActivity or DevActivity report the report contents is
> ChangeLog report contents
> -
>
> Key: MCHANGELOG-12
> URL: http://jira.codehaus.org/browse/MCHANGELOG-12
> Project: Maven 2.x Changelog Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Martin Johannesen
> Assignee: Edwin Punzalan
> Priority: Critical
> Fix For: 2.0
>
>
> Cause:
> DeveloperActivityReport and FileActivityReport both extend ChangeLogReport,
> but the method doGenerateReport has changed signature:
> ChangeLogReport : void doGenerateReport( List changeLogSets, ResourceBundle
> bundle, Sink sink )
> DeveloperActivityReport and FileActivityReport: void doGenerateReport(
> ChangeLogSet changeLogSets, ResourceBundle bundle, Sink sink )
> So when executeReport( Locale locale) is called on DeveloperActivityReport or
> FileActivityReport, the "intended" overridden method doGenerateReport is
> never called, but the parent doGenerateReport from ChangeLogReport, thus
> always generating a ChangeLogReport.
> Due to the fact that this plugin has been moved from mojo to maven, i am not
> able to see when this change has occured. But a possible fix would be to
> change the signature of the above mentioned methods so the parent method gets
> overridden correctly and adding an loop looping over the changeLogSets:
> {code:title=DeveloperActivityReport.java|borderStyle=solid}
>protected void doGenerateReport( List changeLogSets, ResourceBundle
> bundle, Sink sink )
> {
> sink.head();
> sink.title();
> sink.text( bundle.getString( "report.dev-activity.header" ) );
> sink.title_();
> sink.head_();
> sink.body();
> sink.section1();
> sink.sectionTitle1();
> sink.text( bundle.getString( "report.dev-activity.mainTitle" ) );
> sink.sectionTitle1_();
> for ( Iterator sets = changeLogSets.iterator(); sets.hasNext(); )
> {
> ChangeLogSet changeLogSet = (ChangeLogSet) sets.next();
> doChangedSets( changeLogSet, bundle, sink );
> }
> sink.section1_();
> sink.body_();
> sink.flush();
> sink.table_();
> }
> {code}
> {code:title=FileActivityReport|borderStyle=solid}
> protected void doGenerateReport( List changeLogSets, ResourceBundle bundle,
> Sink sink )
> {
> sink.head();
> sink.title();
> sink.text( bundle.getString( "report.file-activity.header" ) );
> sink.title_();
> sink.head_();
> sink.body();
> sink.section1();
> sink.sectionTitle1();
> sink.text( bundle.getString( "report.file-activity.mainTitle" ) );
> sink.sectionTitle1_();
> for ( Iterator sets = changeLogSets.iterator(); sets.hasNext(); )
> {
> ChangeLogSet changeLogSet = (ChangeLogSet) sets.next();
> doChangedSets( changeLogSet, bundle, sink );
> }
>
> sink.section1_();
> sink.body_();
> sink.table_();
> }
> {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] Commented: (MIDEA-35) Module Libraries and WebModule libraries to package should not have a name attribute
[ http://jira.codehaus.org/browse/MIDEA-35?page=comments#action_63299 ] Manfred Geiler commented on MIDEA-35: - No, sorry for bringing you false hope ;-) By "undocumented" I meant that it is not possible from with IDEA GUI to achieve that result. It's only possible to have named module lib definitions when you fiddle with iml files directly. > Module Libraries and WebModule libraries to package should not have a name > attribute > > > Key: MIDEA-35 > URL: http://jira.codehaus.org/browse/MIDEA-35 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Assignee: Edwin Punzalan > Priority: Blocker > Fix For: 2.0 > Attachments: MIDEA-35.patch, idea-2.patch > > > Idea 5.x does not seem to support name attributes in module library > definitions. At least it leads to buggy behavior when WebModule settings are > involved. > There is no way to add a module library with a name from within IDEA. So what > the plugin is using here is an undocumented feature that leads to strange > results. > The solution is to add the module libraries without the name attribute and to > add the WebModule containerElements without a name too. Instead the jar URL > is added to the containerElement. > see applied patch > Cheers, > Manfred -- 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: (MCHANGELOG-15) String index out of range error
[ http://jira.codehaus.org/browse/MCHANGELOG-15?page=all ]
Edwin Punzalan closed MCHANGELOG-15:
Assign To: Edwin Punzalan
Resolution: Fixed
Patch applied. Thanks.
> String index out of range error
> ---
>
> Key: MCHANGELOG-15
> URL: http://jira.codehaus.org/browse/MCHANGELOG-15
> Project: Maven 2.x Changelog Plugin
> Type: Bug
> Versions: 2.0
> Environment: osx 10.4.5, java 1.4.2_09
> Reporter: Julian Wood
> Assignee: Edwin Punzalan
> Priority: Critical
> Fix For: 2.0
> Attachments: MCHANGELOG-15.patch
>
>
> Here's the relevant parts of my pom:
>
> scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk
>
> scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk
>
> http://apollo.ucalgary.ca/websvncommons/listing.php?repname=pmgt&rev=0&sc=0&path=/trunk
>
>
> org.apache.maven.plugins
> maven-changelog-plugin
> 2.0-beta-2-SNAPSHOT
>
>
> changes
>
>
> http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&sc=0&path=
> range
> 60
>
>
> changelog
> file-activity
> dev-activity
>
>
>
>
> I get this error when trying to build my site:
> [INFO] Executing: svn --non-interactive log -v -r "{2006-01-26 21:20:36
> +}:{2006-03-28 21:20:36 +}"
> http://apollo.ucalgary.ca:8800/pmgt/trunk/pmgt-webapp
> [INFO] Working directory:
> /Users/woodj/Documents/pmgt/pmgt/trunk/pmgt-webapp/src/main/java
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] String index out of range: -1
> [INFO]
>
> [INFO] Trace
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1768)
> at java.lang.String.substring(String.java:1735)
> at
> org.apache.maven.changelog.ChangeLogReport.initReportUrls(ChangeLogReport.java:973)
> at
> org.apache.maven.changelog.ChangeLogReport.doChangedSetDetail(ChangeLogReport.java:934)
> ...
--
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: (MCHANGELOG-16) when using svn, links are wrong
[ http://jira.codehaus.org/browse/MCHANGELOG-16?page=all ] Edwin Punzalan closed MCHANGELOG-16: Assign To: Edwin Punzalan Resolution: Fixed Patch applied. Thanks. > when using svn, links are wrong > --- > > Key: MCHANGELOG-16 > URL: http://jira.codehaus.org/browse/MCHANGELOG-16 > Project: Maven 2.x Changelog Plugin > Type: Bug > Versions: 2.0 > Environment: osx 10.4.5, java 1.4.2_09 > Reporter: Julian Wood > Assignee: Edwin Punzalan > Fix For: 2.0 > Attachments: MCHANGELOG-16.patch, test.zip > > > Here's my setup: > > scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk > > scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk > > http://apollo.ucalgary.ca/websvncommons/listing.php?repname=pmgt&rev=0&sc=0&path=/trunk > > ... > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-beta-2-SNAPSHOT > > > changes > > > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&rev=0&sc=0&path= > range > 90 > > > changelog > file-activity > dev-activity > > > > > With that displayFileDetailUrl, I get links like this in the resultant > changelog in my site: > http://apollo.ucalgary.ca/websvncommons/filedetails.php/trunk/pmgt-webapp/src/main/webapp/links/create_groups.jsp?repname=pmgt&sc=0&path= > but it should be like this: > link = > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&sc=0&rev=0&path=/trunk/pmgt-webapp/src/main/webapp/links/create_groups.jsp -- 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-2220) ${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized
${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer
recognized
--
Key: MNG-2220
URL: http://jira.codehaus.org/browse/MNG-2220
Project: Maven 2
Type: Bug
Components: POM
Versions: 2.0.4
Environment: n/a
Reporter: Marcel Schutte
Attachments: buglet.zip
The properties ${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} (and perhaps others as well) are no longer
recognized in pom.xml. The following pom fragment had the desired effect of
copying resources from the sourceDirectory in version 2.0.3, but doesn't work
in 2.0.4:
src
src-test
${pom.build.sourceDirectory}
**/*.properties
${pom.build.testSourceDirectory}
**/mockfiles/
The attached project will fail on a 'mvn test' under maven 2.0.4 and succeed
under 2.0.3
--
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: (MIDEA-49) WebModuleProperties reactor modules: adding with method 5 not compatible with /WEB-INF/classes
WebModuleProperties reactor modules: adding with method 5 not compatible with
/WEB-INF/classes
--
Key: MIDEA-49
URL: http://jira.codehaus.org/browse/MIDEA-49
Project: Maven 2.x Idea Plugin
Type: Bug
Versions: 2.0
Reporter: Manfred Geiler
Currently reactor project modules are added with method "5":
if ( linkModules && isReactorProject( artifact.getGroupId(),
artifact.getArtifactId() ) )
{
containerElement.addAttribute( "type", "module" );
containerElement.addAttribute( "name", artifact.getArtifactId()
);
Element methodAttribute = createElement( containerElement,
"attribute" );
methodAttribute.addAttribute( "name", "method" );
methodAttribute.addAttribute( "value", "5" );
<
Element uriAttribute = createElement( containerElement,
"attribute" );
uriAttribute.addAttribute( "name", "URI" );
uriAttribute.addAttribute( "value", "/WEB-INF/classes" );
}
Well, method "5" seems to be "JAR module output and copy file to" in IDEA. This
method is not compatible with the given URI attribute, which should rather be
something like "/WEB-INF/lib/foobar.jar".
So, one way to fix this is to use method "1" ("Copy module output to") instead,
then the used URI is correct. -->See patch 1.
Another (more maven-style way) is to fix the URI to be "/WEB-INF/lib/" +
artifact.getArtifactId() + "-" + artifact.getVersion() + ".jar". -->See patch 2.
Regards,
Manfred
--
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: (MIDEA-49) WebModuleProperties reactor modules: adding with method 5 not compatible with /WEB-INF/classes
[ http://jira.codehaus.org/browse/MIDEA-49?page=all ]
Manfred Geiler updated MIDEA-49:
Attachment: MIDEA-49-2.patch
> WebModuleProperties reactor modules: adding with method 5 not compatible with
> /WEB-INF/classes
> --
>
> Key: MIDEA-49
> URL: http://jira.codehaus.org/browse/MIDEA-49
> Project: Maven 2.x Idea Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Manfred Geiler
> Attachments: MIDEA-49-1.patch, MIDEA-49-2.patch
>
>
> Currently reactor project modules are added with method "5":
> if ( linkModules && isReactorProject( artifact.getGroupId(),
> artifact.getArtifactId() ) )
> {
> containerElement.addAttribute( "type", "module" );
> containerElement.addAttribute( "name",
> artifact.getArtifactId() );
> Element methodAttribute = createElement( containerElement,
> "attribute" );
> methodAttribute.addAttribute( "name", "method" );
> methodAttribute.addAttribute( "value", "5" );
> <
> Element uriAttribute = createElement( containerElement,
> "attribute" );
> uriAttribute.addAttribute( "name", "URI" );
> uriAttribute.addAttribute( "value", "/WEB-INF/classes" );
> }
> Well, method "5" seems to be "JAR module output and copy file to" in IDEA.
> This method is not compatible with the given URI attribute, which should
> rather be something like "/WEB-INF/lib/foobar.jar".
> So, one way to fix this is to use method "1" ("Copy module output to")
> instead, then the used URI is correct. -->See patch 1.
> Another (more maven-style way) is to fix the URI to be "/WEB-INF/lib/" +
> artifact.getArtifactId() + "-" + artifact.getVersion() + ".jar". -->See patch
> 2.
> Regards,
> Manfred
--
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: (MIDEA-49) WebModuleProperties reactor modules: adding with method 5 not compatible with /WEB-INF/classes
[ http://jira.codehaus.org/browse/MIDEA-49?page=all ]
Manfred Geiler updated MIDEA-49:
Attachment: MIDEA-49-1.patch
> WebModuleProperties reactor modules: adding with method 5 not compatible with
> /WEB-INF/classes
> --
>
> Key: MIDEA-49
> URL: http://jira.codehaus.org/browse/MIDEA-49
> Project: Maven 2.x Idea Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Manfred Geiler
> Attachments: MIDEA-49-1.patch, MIDEA-49-2.patch
>
>
> Currently reactor project modules are added with method "5":
> if ( linkModules && isReactorProject( artifact.getGroupId(),
> artifact.getArtifactId() ) )
> {
> containerElement.addAttribute( "type", "module" );
> containerElement.addAttribute( "name",
> artifact.getArtifactId() );
> Element methodAttribute = createElement( containerElement,
> "attribute" );
> methodAttribute.addAttribute( "name", "method" );
> methodAttribute.addAttribute( "value", "5" );
> <
> Element uriAttribute = createElement( containerElement,
> "attribute" );
> uriAttribute.addAttribute( "name", "URI" );
> uriAttribute.addAttribute( "value", "/WEB-INF/classes" );
> }
> Well, method "5" seems to be "JAR module output and copy file to" in IDEA.
> This method is not compatible with the given URI attribute, which should
> rather be something like "/WEB-INF/lib/foobar.jar".
> So, one way to fix this is to use method "1" ("Copy module output to")
> instead, then the used URI is correct. -->See patch 1.
> Another (more maven-style way) is to fix the URI to be "/WEB-INF/lib/" +
> artifact.getArtifactId() + "-" + artifact.getVersion() + ".jar". -->See patch
> 2.
> Regards,
> Manfred
--
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: (MJAR-21) JarSign cleanups
[ http://jira.codehaus.org/browse/MJAR-21?page=all ] Kenney Westerhof closed MJAR-21: Resolution: Fixed Fixed in revision 393197. I undid the changes to make two methods private instead of package protected, since this constitutes an API change. If this is still required, can someone OK this and reopen this issue? > JarSign cleanups > > > Key: MJAR-21 > URL: http://jira.codehaus.org/browse/MJAR-21 > Project: Maven 2.x Jar Plugin > Type: Improvement > Reporter: Jerome Lacoste > Attachments: jar-cleanups.diff > > > Cleanups related to a forthcoming patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGELOG-34) Add tests to changelog-plugin and utilize the testing-harness
[ http://jira.codehaus.org/browse/MCHANGELOG-34?page=all ] Edwin Punzalan closed MCHANGELOG-34: Resolution: Fixed Fixed in SVN > Add tests to changelog-plugin and utilize the testing-harness > - > > Key: MCHANGELOG-34 > URL: http://jira.codehaus.org/browse/MCHANGELOG-34 > Project: Maven 2.x Changelog Plugin > Type: Test > Reporter: Edwin Punzalan > Assignee: Edwin Punzalan > > -- 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: (MJAR-22) Allow to programatically identify between types of sign failures
[ http://jira.codehaus.org/browse/MJAR-22?page=all ] Kenney Westerhof closed MJAR-22: Resolution: Fixed Applied patch in revision 393202. Applied some code formatting. > Allow to programatically identify between types of sign failures > > > Key: MJAR-22 > URL: http://jira.codehaus.org/browse/MJAR-22 > Project: Maven 2.x Jar Plugin > Type: New Feature > Reporter: Jerome Lacoste > Priority: Blocker > Attachments: jarsign-failure.diff > > > Patch by Richard Allen <[EMAIL PROTECTED]> > Slightly cleaned up by Jerome Lacoste ([EMAIL PROTECTED]) > We need this for upcoming functionality related to webstart plugin. -- 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: (MJAR-23) Add a global property for skipping jar signing
[ http://jira.codehaus.org/browse/MJAR-23?page=all ]
Kenney Westerhof closed MJAR-23:
Resolution: Fixed
Committed in revision 393203.
> Add a global property for skipping jar signing
> --
>
> Key: MJAR-23
> URL: http://jira.codehaus.org/browse/MJAR-23
> Project: Maven 2.x Jar Plugin
> Type: New Feature
> Reporter: Jerome Lacoste
> Priority: Minor
> Attachments: jarsign-skip.diff
>
>
> /**
> * Set this to true to disable signing. Useful to speed up
> build process in development environment.
> *
> * @parameter expression="${maven.jar.sign.skip}" default-value="false"
> */
> Patch by Richard Allen <[EMAIL PROTECTED]>
> Documentation by Jerome Lacoste ([EMAIL PROTECTED])
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-30) site:deploy incompatibilities with m1.02
[ http://jira.codehaus.org/browse/MSITE-30?page=comments#action_63309 ] Paul Spencer commented on MSITE-30: --- Is this in part a WAGGON issue since it is in AbstractWaggon.createZip where the type compression, either ZIP or GZIP, is set? A suggestion: Allow the plugin/Waggon to determine what is supported on the remote side, (zip, gzip, tar,...) and then use what is available. Paul Spencer > site:deploy incompatibilities with m1.02 > > > Key: MSITE-30 > URL: http://jira.codehaus.org/browse/MSITE-30 > Project: Maven 2.x Site Plugin > Type: Bug > Environment: All > Reporter: Paul Spencer > Fix For: 2.0 > > > Deploying a site in m2 has changed since m1. > 1) m1 used the "tar" and "gunzip" command on the remote site, where m2 uses > the "unzip" command. This poses a problem for be since my remote site does > not support the "unzip" command, thus making the "priority" of this issue > major > 1.1) Their may be desire to deploy without the use of tools like tar and zip > on some site. The deploy would esentailly be a recersive copy > 2) No equivelent to m1 property maven.site.chmod.mode. I use this to allow > other member is the group update and delete permission > 3) No equivelent to m1 property maven.site.publish.clean > Their are other properties for the m1.02 not mentioned above, but I suspect > the they can be calculated from m2 files, i.e. pom.xml and settings.xml. > Paul Spencer -- 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-2221) Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times
Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times - Key: MNG-2221 URL: http://jira.codehaus.org/browse/MNG-2221 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0.4 Reporter: Stephen Duncan Jr Priority: Critical Attachments: repeat-test.zip Can occur in a variety of ways, but the attached test case shows a parent pom defining an antrun-execution, and then a child specifying another execution with a different id. Both executions run twice when running from the child. I believe this is the same as Kenney Westerhof's comment: http://jira.codehaus.org/browse/MNG-2054#action_62477 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2054) Multiple Inheritence causes plugin executions to run multiple times (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2054?page=comments#action_63310 ]
Stephen Duncan Jr commented on MNG-2054:
I've filed http://jira.codehaus.org/browse/MNG-2221 which I think is the same
as Kenney's.
> Multiple Inheritence causes plugin executions to run multiple times (Test
> Case Attached)
>
>
> Key: MNG-2054
> URL: http://jira.codehaus.org/browse/MNG-2054
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.2
> Environment: WinXp
> Reporter: Brian Fox
> Assignee: Brett Porter
> Priority: Critical
> Fix For: 2.0.4
> Attachments: antrun2.tgz, sample-regression.zip, sample.zip
>
>
> See the attached sample. If a plugin execution is set in a parent of a
> parent, when the child is built from either aggregator, the plugin execution
> runs multiple times. In my sample, I set the sources to be generated, but
> when run, see that the sources are generated and installed 2x.
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> [INFO] [install:install]
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar to
> f:\mavenRepo\sampl
> e-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> to f:\mavenRe
> po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> to f:\mavenRe
> po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> to f:\mavenRepo
> \sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-tests.jar
> [INFO]
> If run directly from the child build, the sources are only built 1x:
> [INFO] [jar:jar]
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar
> [INFO] [source:jar {execution: attach-source}]
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> [INFO] [jar:test-jar {execution: default}]
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> [INFO] [install:install]
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar to
> f:\mavenRepo\sampl
> e-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> to f:\mavenRe
> po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> to f:\mavenRepo
> \sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-tests.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] Commented: (MNG-2221) Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times
[ http://jira.codehaus.org/browse/MNG-2221?page=comments#action_63311 ] Stephen Duncan Jr commented on MNG-2221: More details on how to run the test. cd repeat-parent-test mvn install cd ../repeat-child-test mvn package You will see 2 executions of each antrun. > Multiple Executions of Plugin at Difference Inhertiance levels causes plugin > executions to run multiple times > - > > Key: MNG-2221 > URL: http://jira.codehaus.org/browse/MNG-2221 > Project: Maven 2 > Type: Bug > Components: Inheritence and Interpolation > Versions: 2.0.4 > Reporter: Stephen Duncan Jr > Priority: Critical > Attachments: repeat-test.zip > > > Can occur in a variety of ways, but the attached test case shows a parent pom > defining an antrun-execution, and then a child specifying another execution > with a different id. Both executions run twice when running from the child. > I believe this is the same as Kenney Westerhof's comment: > http://jira.codehaus.org/browse/MNG-2054#action_62477 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPA-56) Process Fabrice Bellingard
[ http://jira.codehaus.org/browse/MPA-56?page=all ] Jason van Zyl closed MPA-56: Resolution: Fixed Account setup and SVN access granted. > Process Fabrice Bellingard > -- > > Key: MPA-56 > URL: http://jira.codehaus.org/browse/MPA-56 > Project: Maven Project Administration > Type: Task > Components: New Committers > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 2006-q1 > > -- 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: (MPA-58) Process Maria Odea Ching
[ http://jira.codehaus.org/browse/MPA-58?page=all ] Jason van Zyl closed MPA-58: Resolution: Fixed Account setup and SVN access granted. > Process Maria Odea Ching > > > Key: MPA-58 > URL: http://jira.codehaus.org/browse/MPA-58 > Project: Maven Project Administration > Type: Task > Components: New Committers > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 2006-q1 > > -- 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: (MPA-59) Process John Tolentino
[ http://jira.codehaus.org/browse/MPA-59?page=all ] Jason van Zyl closed MPA-59: Resolution: Fixed Account setup and SVN access granted. > Process John Tolentino > -- > > Key: MPA-59 > URL: http://jira.codehaus.org/browse/MPA-59 > Project: Maven Project Administration > Type: Task > Components: New Committers > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 2006-q1 > > -- 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: (MPA-60) Process Jesse McConnell
[ http://jira.codehaus.org/browse/MPA-60?page=all ] Jason van Zyl closed MPA-60: Resolution: Fixed Account setup and SVN access granted. > Process Jesse McConnell > --- > > Key: MPA-60 > URL: http://jira.codehaus.org/browse/MPA-60 > Project: Maven Project Administration > Type: Task > Components: New Committers > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 2006-q1 > > -- 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: (MPA-61) Process Milos Kleint
[ http://jira.codehaus.org/browse/MPA-61?page=all ] Jason van Zyl closed MPA-61: Resolution: Fixed Account setup and SVN access granted. > Process Milos Kleint > > > Key: MPA-61 > URL: http://jira.codehaus.org/browse/MPA-61 > Project: Maven Project Administration > Type: Task > Components: New Committers > Versions: 2006-q1 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 2006-q1 > > > CLA is on file, waiting for root account to be setup. -- 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: (MJAR-24) don't sign already signed jars (also allow for in-place jar signing)
[ http://jira.codehaus.org/browse/MJAR-24?page=all ] Jerome Lacoste updated MJAR-24: --- Attachment: MJAR-24-v2.diff > don't sign already signed jars (also allow for in-place jar signing) > > > Key: MJAR-24 > URL: http://jira.codehaus.org/browse/MJAR-24 > Project: Maven 2.x Jar Plugin > Type: Improvement > Reporter: Jerome Lacoste > Priority: Critical > Attachments: MJAR-24-v2.diff, jarsign-skipsignedjars.diff > > > Patch by Richard Allen <[EMAIL PROTECTED]> > Documentation by Jerome Lacoste ([EMAIL PROTECTED]) > - allows for in-place signing of the jar. > - avoid signing the jar twice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-372) activemq 4.0rc2 is not deployed to ibiblio
activemq 4.0rc2 is not deployed to ibiblio -- Key: MEV-372 URL: http://jira.codehaus.org/browse/MEV-372 Project: Maven Evangelism Type: Wish Components: Missing POM Reporter: Michael Mattox there is 4.0m2 but not rc2. maybe this is the same thing, in which case the rc2 should be used because that's the official name on the activemq site. -- 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: (MJAR-24) don't sign already signed jars (also allow for in-place jar signing)
[ http://jira.codehaus.org/browse/MJAR-24?page=all ] Kenney Westerhof closed MJAR-24: Assign To: Kenney Westerhof Resolution: Fixed Committed in revision 393237, with minor modifications. > don't sign already signed jars (also allow for in-place jar signing) > > > Key: MJAR-24 > URL: http://jira.codehaus.org/browse/MJAR-24 > Project: Maven 2.x Jar Plugin > Type: Improvement > Reporter: Jerome Lacoste > Assignee: Kenney Westerhof > Priority: Critical > Attachments: MJAR-24-v2.diff, jarsign-skipsignedjars.diff > > > Patch by Richard Allen <[EMAIL PROTECTED]> > Documentation by Jerome Lacoste ([EMAIL PROTECTED]) > - allows for in-place signing of the jar. > - avoid signing the jar twice. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-32) [JarSignMojo] Verification of a signed jar fails
[ http://jira.codehaus.org/browse/MJAR-32?page=comments#action_63321 ] Jerome Lacoste commented on MJAR-32: This one was partially fixed as part of MJAR-24. I have to re-write the unit tests though. > [JarSignMojo] Verification of a signed jar fails > > > Key: MJAR-32 > URL: http://jira.codehaus.org/browse/MJAR-32 > Project: Maven 2.x Jar Plugin > Type: Bug > Environment: Linux Slackware 10.1, JDK 1.4.2_02 > Reporter: Pawel Pastula > Priority: Blocker > Attachments: MJAR-32.diff > > > When verification is executed there is no way the verification can succeed > since if uses unsigned jar file instead of signedjar file: > verify.setJarPath( getJarFile() ); in JarSignMojo.java:182. -- 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: (MASSEMBLY-63) Documentatin points to invalid svn archive location
[ http://jira.codehaus.org/browse/MASSEMBLY-63?page=comments#action_63322 ] shean chang commented on MASSEMBLY-63: -- The link is still not correct. Could someone post the correct link here? > Documentatin points to invalid svn archive location > --- > > Key: MASSEMBLY-63 > URL: http://jira.codehaus.org/browse/MASSEMBLY-63 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Nigel Magnay > Assignee: Brett Porter > Priority: Minor > > > http://maven.apache.org/plugins/maven-assembly-plugin/source-repository.html > states that the source is at > http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-assembly-plugin > Following that link leads to an error page -- 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: (MASSEMBLY-63) Documentatin points to invalid svn archive location
[ http://jira.codehaus.org/browse/MASSEMBLY-63?page=comments#action_63323 ] Dan Tran commented on MASSEMBLY-63: --- http://svn.apache.org/repos/asf/maven/plugins/trunk > Documentatin points to invalid svn archive location > --- > > Key: MASSEMBLY-63 > URL: http://jira.codehaus.org/browse/MASSEMBLY-63 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Nigel Magnay > Assignee: Brett Porter > Priority: Minor > > > http://maven.apache.org/plugins/maven-assembly-plugin/source-repository.html > states that the source is at > http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-assembly-plugin > Following that link leads to an error page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVEN-1752) Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.(I)V
Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.(I)V Key: MAVEN-1752 URL: http://jira.codehaus.org/browse/MAVEN-1752 Project: Maven Type: Bug Versions: 1.1-beta-3 Environment: Windows 2000 maven-1.1-beta-2 maven-1.1-beta-3-SNAPSHOT Reporter: Maxim Gubin Fix For: 1.1-beta-2, 1.1-beta-3 A strange error has begun occuring. I uninstalled maven once for whatever reason, and after that I began getting this error. And no matter what version of Maven I switch to, I get the same error. I started getting this error on version 1.1-beta-2 and saw a suggestion to try the snapshot, and it's doing the same thing. Does anyone know what this relates to? Here's the snippet: C:\dev\maven-test>maven __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT Plugin cache will be regenerated java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.(I)V at org.apache.crimson.parser.Parser2.(Parser2.java:179) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:429) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:157) at org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:177) at org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManager.java:238) at org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:303) at org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) at org.apache.maven.MavenSession.initialize(MavenSession.java:171) at org.apache.maven.cli.App.doMain(App.java:498) at org.apache.maven.cli.App.main(App.java:1258) 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 com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) You have encountered an unknown error running Maven. Please help us to correct this problem by following these simple steps: - read the Maven FAQ at http://maven.apache.org/faq.html - run the same command again with the '-e' parameter, eg 'maven -e jar' - search the maven-user archives for the error at http://www.mail-archive.com/users@maven.apache.org - post the output of maven -e to JIRA at http://jira.codehaus.org/browse/MAVEN (you must sign up first) - run 'maven --info' and post the output as the environment to the bug above Total time : 0 seconds Finished at : Tuesday, April 11, 2006 11:34:37 AM EDT C:\dev\maven-test>maven -X __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT Initializing Plugins! Context [28910606] : variable [maven] => value = [null] Context [28910606] : variable [maven.home] => value = [C:\maven-1.1-beta3-20051210] Context [28910606] : variable [maven.plugin.dir] => value = [C:\maven-1.1-beta3-20051210/plugins] Context [28910606] : variable [maven] => value = [null] Context [28910606] : variable [maven.home] => value = [C:\maven-1.1-beta3-20051210] Context [28910606] : variable [user] => value = [null] Context [28910606] : variable [user.home] => value = [C:\Documents and Settings\mgubin] Context [28910606] : variable [maven.home.local] => value = [C:\Documents and Settings\mgubin/.maven] Context [28910606] : variable [maven.plugin.unpacked.dir] => value = [C:\Documents and Settings\mgubin/.maven/cache] Context [28910606] : variable [maven] => value = [null] Context [28910606] : variable [maven.home] => value = [C:\maven-1.1-beta3-20051210] Context [28910606] : variable [user] => value = [null] Context [28910606] : variable [user.home] => value = [C:\Documents and Settings\mgubin] Context [28910606] : variable [maven.home.local] => value = [C:\Documents and Settings\mgubin/.maven] Context [28910606] : variable [maven.plugin.user.dir] => value = [C:\Documents and Settings\mgubin/.maven/plugins] Set plugin source directory to C:\maven-1.1-beta3-20051210\plugins Set unpacked plugin directory to C:\Documents and Settings\mgubin\.maven\cache Set user plugin directory to C:\Documents and Settings\mgubin\.maven\plugins Plugin cache will be regenerated Now mapping cached plugins Now loading uncached plugins Loading plugin 'maven-cruisecontrol-plugin-1.8-SNAPSHOT' Using userBuildPropertiesFile: C:\Documents and Settings\mgubin\build.properties Using proj
[jira] Created: (MNG-2222) dependency to dependency without source code fails
dependency to dependency without source code fails -- Key: MNG- URL: http://jira.codehaus.org/browse/MNG- Project: Maven 2 Type: Bug Components: Dependencies Versions: 2.0.4 Environment: Linux apple 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04:03:26 EDT 2005 i686 i686 i386 GNU/Linux java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) Reporter: Michael Mosmann - project1 - project2 (dep project1) - project3 (dep project2) - parent pom (module project1,project2,project3) mvn compile build project1 build project2 [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date build project3 [INFO] Failed to resolve artifact. in project2 no target created --- Workaround put Noop.java into source so it will build some sources -- 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: (DOXIA-58) snapshot failed doxia-site-renderer-1.0-alpha-8-20060411.133534-1
snapshot failed doxia-site-renderer-1.0-alpha-8-20060411.133534-1 - Key: DOXIA-58 URL: http://jira.codehaus.org/browse/DOXIA-58 Project: doxia Type: Bug Components: Site Renderer Versions: 1.0-alpha-8 Environment: all Reporter: Olivier Lamy with doxia-site-renderer-1.0-alpha-8-20060411.133534-1 I have the stack trace [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.doxia.siterenderer.Renderer.render(Ljava/util/Collectio n;Lorg/apache/maven/d oxia/siterenderer/SiteRenderingContext;Ljava/io/File;Ljava/lang/String;) V [INFO] [INFO] Trace java.lang.NoSuchMethodError: org.apache.maven.doxia.siterenderer.Renderer.render(Ljava/util/Collecti on;Lorg/apache/maven/doxia/siterenderer/SiteRenderingContext;Ljava/io/Fi le;Ljava/lang/String;)V at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:121) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor .java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifec ycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor. java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(Default -- 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: (MEAR-8) Add security role definitions to maven-ear-plugin
[ http://jira.codehaus.org/browse/MEAR-8?page=all ]
Stephane Nicoll closed MEAR-8:
--
Resolution: Fixed
Implemented. The pom described in this issue will work as is.
Check howto.apt for more details.
> Add security role definitions to maven-ear-plugin
> -
>
> Key: MEAR-8
> URL: http://jira.codehaus.org/browse/MEAR-8
> Project: Maven 2.x Ear Plugin
> Type: Improvement
> Reporter: Martijn de Bruijn
> Assignee: Stephane Nicoll
> Priority: Minor
> Fix For: 2.2
>
>
> The maven-ear-plugin is not capable of defining security-roles. This should
> be added.
> An example of the pom.xml:
>
> org.apache.maven.plugins
> maven-ear-plugin
>
> ${basedir}/META-INF
>
>
>
> manager
>
>
>
> teller
>
>
>
>
> It should be possible to add the id field to the security-role element to be
> able to link the roles to other generated artifacts.
--
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-2155) ehcache is now using Maven 2.0. Can it be added to the powered by list?
[ http://jira.codehaus.org/browse/MNG-2155?page=comments#action_6 ] Natalie Burdick commented on MNG-2155: -- Carlos, when is next time for site regeneration? also, can we give them a maven logo for their site? > ehcache is now using Maven 2.0. Can it be added to the powered by list? > > > Key: MNG-2155 > URL: http://jira.codehaus.org/browse/MNG-2155 > Project: Maven 2 > Type: Wish > Components: Sites & Reporting > Versions: 2.0.2 > Reporter: Greg Luck > Assignee: Carlos Sanchez > > > Hi guys. I have uploaded the new ehcache web site: ehcache.sf.net, which is > completely built and deployed using maven 2.0. It uses most of the plugins > relevant to reporting and a web site and I think is a good example of what > can be done. > Any chance of being added to the powered by list on the powered-by-m2? > I am not using the powered by logo because it does not suite the site but I > am acknowledging the site was built using maven on the home page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-654) Add command line options to override M2_HOME and JAVA_HOME
Add command line options to override M2_HOME and JAVA_HOME -- Key: CONTINUUM-654 URL: http://jira.codehaus.org/browse/CONTINUUM-654 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.3 Reporter: Carlos Sanchez Assigned to: Emmanuel Venisse Fix For: 1.0.3 When installing as service under windows, the wrapper doesn't allow modifying environment variables, so it's not possible to have two continuums under the same account using different M2_HOME or JAVA_HOME. Looks like path can be configured in the wrapper.conf. I continuum allowed command line arguments to override this value we could feed them from the wrapper config -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-17) Jar files packed in the EAR file should also be added to application.xml or manifest.mf
[ http://jira.codehaus.org/browse/MEAR-17?page=comments#action_63334 ] Stephane Nicoll commented on MEAR-17: - Mark, any suggestion for this use case? > Jar files packed in the EAR file should also be added to application.xml or > manifest.mf > --- > > Key: MEAR-17 > URL: http://jira.codehaus.org/browse/MEAR-17 > Project: Maven 2.x Ear Plugin > Type: Improvement > Reporter: Kristoffer Peterhäesel > Assignee: Stephane Nicoll > Fix For: 2.2 > > > While attempting to package an EAR for deployment on JBoss I have come across > a (for me) major issue with the way this module works. > The issue is that there are a lot dependency jars included by default. That > by itself isn't the problem. The problem is there is no way to include it in > the classpath without defining all the dependencies again in the pom.xml for > the EAR. > In an ideal world (for me) the jars would be an easy way to add the jars to > the classpath since I want to include all I need in the EAR to make it as > easy as possible to set up a depoyment environment. > There are really two options for how to do that. Either the jar files are > added to the generated Manifest.MF file or else there should be a simple > option to include all packed jar files to the application.xml. Both should > (AFAIK) work in any standard-compliant container. > The option of putting all the jar files in APP-INF/lib only works on Weblogic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-654) Add command line options to override M2_HOME and JAVA_HOME
[ http://jira.codehaus.org/browse/CONTINUUM-654?page=all ] Carlos Sanchez closed CONTINUUM-654: Assign To: Carlos Sanchez (was: Emmanuel Venisse) Resolution: Won't Fix Fix Version: (was: 1.0.3) It was just a matter of setting some properties in the wrapper.conf # Set MAVEN_HOME and JAVA_HOME set.M2_HOME=D:/maven/maven-2.0.3 set.PATH=%M2_HOME%/bin;%PATH% More info http://wrapper.tanukisoftware.org/doc/english/props-envvars.html > Add command line options to override M2_HOME and JAVA_HOME > -- > > Key: CONTINUUM-654 > URL: http://jira.codehaus.org/browse/CONTINUUM-654 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.3 > Reporter: Carlos Sanchez > Assignee: Carlos Sanchez > > > When installing as service under windows, the wrapper doesn't allow modifying > environment variables, so it's not possible to have two continuums under the > same account using different M2_HOME or JAVA_HOME. Looks like path can be > configured in the wrapper.conf. > I continuum allowed command line arguments to override this value we could > feed them from the wrapper config -- 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-2155) ehcache is now using Maven 2.0. Can it be added to the powered by list?
[ http://jira.codehaus.org/browse/MNG-2155?page=comments#action_63337 ] Carlos Sanchez commented on MNG-2155: - Already there http://maven.apache.org/powered-by-m2.html Can we ask for a "Built by Maven" reference in exchange? > ehcache is now using Maven 2.0. Can it be added to the powered by list? > > > Key: MNG-2155 > URL: http://jira.codehaus.org/browse/MNG-2155 > Project: Maven 2 > Type: Wish > Components: Sites & Reporting > Versions: 2.0.2 > Reporter: Greg Luck > Assignee: Carlos Sanchez > > > Hi guys. I have uploaded the new ehcache web site: ehcache.sf.net, which is > completely built and deployed using maven 2.0. It uses most of the plugins > relevant to reporting and a web site and I think is a good example of what > can be done. > Any chance of being added to the powered by list on the powered-by-m2? > I am not using the powered by logo because it does not suite the site but I > am acknowledging the site was built using maven on the home page. -- 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-1752) Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.(I)V
[ http://jira.codehaus.org/browse/MAVEN-1752?page=comments#action_63342 ] Arnaud Heritier commented on MAVEN-1752: What is your path (%PATH%) ? Don't you have an old maven installation before the new one in the path ? Did you try to remove your plugins cache to see if it's not corrupted ? Did you try to temporary move your repository to test if you don't have a corrupted jar somewhere ? Did you test your rt.jar (jar -tvf rt.jar) in your jdk to see if these jar isn't corrupted ? > Strange bug that renders my maven useless: java.lang.NoSuchMethodError: > org.apache.crimson.parser.SimpleHashtable.(I)V > > > Key: MAVEN-1752 > URL: http://jira.codehaus.org/browse/MAVEN-1752 > Project: Maven > Type: Bug > Versions: 1.1-beta-3 > Environment: Windows 2000 > maven-1.1-beta-2 > maven-1.1-beta-3-SNAPSHOT > Reporter: Gubinator > Fix For: 1.1-beta-2, 1.1-beta-3 > > > A strange error has begun occuring. I uninstalled maven once for whatever > reason, and after that I began getting this error. > And no matter what version of Maven I switch to, I get the same error. I > started getting this error on version 1.1-beta-2 and saw a suggestion to try > the snapshot, and it's doing the same thing. > Does anyone know what this relates to? > Here's the snippet: > C:\dev\maven-test>maven > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT > Plugin cache will be regenerated > java.lang.NoSuchMethodError: > org.apache.crimson.parser.SimpleHashtable.(I)V > at org.apache.crimson.parser.Parser2.(Parser2.java:179) > at > org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:429) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) > at > org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:157) > at > org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:177) > at > org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManager.java:238) > at > org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:303) > at > org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) > at org.apache.maven.MavenSession.initialize(MavenSession.java:171) > at org.apache.maven.cli.App.doMain(App.java:498) > at org.apache.maven.cli.App.main(App.java:1258) > 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 com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > You have encountered an unknown error running Maven. > Please help us to correct this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/faq.html > - run the same command again with the '-e' parameter, eg 'maven -e jar' > - search the maven-user archives for the error at > http://www.mail-archive.com/users@maven.apache.org > - post the output of maven -e to JIRA at > http://jira.codehaus.org/browse/MAVEN (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > Total time : 0 seconds > Finished at : Tuesday, April 11, 2006 11:34:37 AM EDT > C:\dev\maven-test>maven -X > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT > Initializing Plugins! > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [maven.plugin.dir] => value = > [C:\maven-1.1-beta3-20051210/plugins] > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [user] => value = [null] > Context [28910606] : variable [user.home] => value = [C:\Documents and > Settings\mgubin] > Context [28910606] : variable [maven.home.local] => value = [C:\Documents and > Settings\mgubin/.maven] > Context [28910606] : variable [maven.plugin.unpacked.dir] => value = > [C:\Documents and Settings\mgubin/.maven/cache] > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [user] => value = [null] > Context [28910606] : variable [user.home] => value = [C:\Docum
[jira] Updated: (MAVEN-1726) CLONE -Add the possibility to use parent pom present in repo
[ http://jira.codehaus.org/browse/MAVEN-1726?page=all ]
Arnaud Heritier updated MAVEN-1726:
---
Priority: Minor (was: Blocker)
> CLONE -Add the possibility to use parent pom present in repo
>
>
> Key: MAVEN-1726
> URL: http://jira.codehaus.org/browse/MAVEN-1726
> Project: Maven
> Type: New Feature
> Versions: 1.1-beta-3, 1.1-beta-1, 1.0.2, 1.1-beta-2
> Reporter: Manfred Mayer
> Priority: Minor
> Fix For: 1.1-beta-3, 1.0.1
> Attachments: MAVEN-1726.txt
>
>
> For the extend tag, we can support http protocol, or another syntax like this
> ${repo}/aGroupId/poms/anArtifactId-version.pom. Personally,
> I prefer the second solution.
> With this features, users can share default pom parameter between all their
> projects, and it prepare the introduction of pom V4.
--
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-1726) CLONE -Add the possibility to use parent pom present in repo
[ http://jira.codehaus.org/browse/MAVEN-1726?page=all ]
Arnaud Heritier updated MAVEN-1726:
---
Fix Version: (was: 1.0.1)
> CLONE -Add the possibility to use parent pom present in repo
>
>
> Key: MAVEN-1726
> URL: http://jira.codehaus.org/browse/MAVEN-1726
> Project: Maven
> Type: New Feature
> Versions: 1.1-beta-3, 1.1-beta-1, 1.0.2, 1.1-beta-2
> Reporter: Manfred Mayer
> Priority: Minor
> Fix For: 1.1-beta-3
> Attachments: MAVEN-1726.txt
>
>
> For the extend tag, we can support http protocol, or another syntax like this
> ${repo}/aGroupId/poms/anArtifactId-version.pom. Personally,
> I prefer the second solution.
> With this features, users can share default pom parameter between all their
> projects, and it prepare the introduction of pom V4.
--
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-1752) Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.(I)V
[ http://jira.codehaus.org/browse/MAVEN-1752?page=all ] Arnaud Heritier updated MAVEN-1752: --- Fix Version: (was: 1.1-beta-3) (was: 1.1-beta-2) > Strange bug that renders my maven useless: java.lang.NoSuchMethodError: > org.apache.crimson.parser.SimpleHashtable.(I)V > > > Key: MAVEN-1752 > URL: http://jira.codehaus.org/browse/MAVEN-1752 > Project: Maven > Type: Bug > Versions: 1.1-beta-3 > Environment: Windows 2000 > maven-1.1-beta-2 > maven-1.1-beta-3-SNAPSHOT > Reporter: Gubinator > > > A strange error has begun occuring. I uninstalled maven once for whatever > reason, and after that I began getting this error. > And no matter what version of Maven I switch to, I get the same error. I > started getting this error on version 1.1-beta-2 and saw a suggestion to try > the snapshot, and it's doing the same thing. > Does anyone know what this relates to? > Here's the snippet: > C:\dev\maven-test>maven > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT > Plugin cache will be regenerated > java.lang.NoSuchMethodError: > org.apache.crimson.parser.SimpleHashtable.(I)V > at org.apache.crimson.parser.Parser2.(Parser2.java:179) > at > org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:429) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) > at > org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:157) > at > org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:177) > at > org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManager.java:238) > at > org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:303) > at > org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) > at org.apache.maven.MavenSession.initialize(MavenSession.java:171) > at org.apache.maven.cli.App.doMain(App.java:498) > at org.apache.maven.cli.App.main(App.java:1258) > 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 com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > You have encountered an unknown error running Maven. > Please help us to correct this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/faq.html > - run the same command again with the '-e' parameter, eg 'maven -e jar' > - search the maven-user archives for the error at > http://www.mail-archive.com/users@maven.apache.org > - post the output of maven -e to JIRA at > http://jira.codehaus.org/browse/MAVEN (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > Total time : 0 seconds > Finished at : Tuesday, April 11, 2006 11:34:37 AM EDT > C:\dev\maven-test>maven -X > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT > Initializing Plugins! > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [maven.plugin.dir] => value = > [C:\maven-1.1-beta3-20051210/plugins] > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [user] => value = [null] > Context [28910606] : variable [user.home] => value = [C:\Documents and > Settings\mgubin] > Context [28910606] : variable [maven.home.local] => value = [C:\Documents and > Settings\mgubin/.maven] > Context [28910606] : variable [maven.plugin.unpacked.dir] => value = > [C:\Documents and Settings\mgubin/.maven/cache] > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [user] => value = [null] > Context [28910606] : variable [user.home] => value = [C:\Documents and > Settings\mgubin] > Context [28910606] : variable [maven.home.local] => value = [C:\Documents and > Settings\mgubin/.maven] > Context [28910606] : variable [maven.plugin.user.dir] => value = > [C:\Documents and Settings\mgubin/.maven/plugins] > Set plugin source directory to C:\maven-1.1-beta3-20051210\plugins > Set unpacked plugin directory to C
[jira] Closed: (MAVEN-1752) Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.(I)V
[ http://jira.codehaus.org/browse/MAVEN-1752?page=all ] Gubinator closed MAVEN-1752: Resolution: Fixed Yes, this issue was resolved. Apparently at some point I changed my jdk path to that of java 1.4.2_11 and I think what happened was that some of the xml parsing jars were removed from that version. So after switching my JAVA_HOME to 1.4.2_06, it magically started working! > Strange bug that renders my maven useless: java.lang.NoSuchMethodError: > org.apache.crimson.parser.SimpleHashtable.(I)V > > > Key: MAVEN-1752 > URL: http://jira.codehaus.org/browse/MAVEN-1752 > Project: Maven > Type: Bug > Versions: 1.1-beta-3 > Environment: Windows 2000 > maven-1.1-beta-2 > maven-1.1-beta-3-SNAPSHOT > Reporter: Gubinator > > > A strange error has begun occuring. I uninstalled maven once for whatever > reason, and after that I began getting this error. > And no matter what version of Maven I switch to, I get the same error. I > started getting this error on version 1.1-beta-2 and saw a suggestion to try > the snapshot, and it's doing the same thing. > Does anyone know what this relates to? > Here's the snippet: > C:\dev\maven-test>maven > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT > Plugin cache will be regenerated > java.lang.NoSuchMethodError: > org.apache.crimson.parser.SimpleHashtable.(I)V > at org.apache.crimson.parser.Parser2.(Parser2.java:179) > at > org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:429) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) > at > org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:157) > at > org.apache.maven.plugin.JellyScriptHousing.parse(JellyScriptHousing.java:177) > at > org.apache.maven.plugin.PluginManager.loadUncachedPlugins(PluginManager.java:238) > at > org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:303) > at > org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) > at org.apache.maven.MavenSession.initialize(MavenSession.java:171) > at org.apache.maven.cli.App.doMain(App.java:498) > at org.apache.maven.cli.App.main(App.java:1258) > 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 com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > You have encountered an unknown error running Maven. > Please help us to correct this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/faq.html > - run the same command again with the '-e' parameter, eg 'maven -e jar' > - search the maven-user archives for the error at > http://www.mail-archive.com/users@maven.apache.org > - post the output of maven -e to JIRA at > http://jira.codehaus.org/browse/MAVEN (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > Total time : 0 seconds > Finished at : Tuesday, April 11, 2006 11:34:37 AM EDT > C:\dev\maven-test>maven -X > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT > Initializing Plugins! > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [maven.plugin.dir] => value = > [C:\maven-1.1-beta3-20051210/plugins] > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [user] => value = [null] > Context [28910606] : variable [user.home] => value = [C:\Documents and > Settings\mgubin] > Context [28910606] : variable [maven.home.local] => value = [C:\Documents and > Settings\mgubin/.maven] > Context [28910606] : variable [maven.plugin.unpacked.dir] => value = > [C:\Documents and Settings\mgubin/.maven/cache] > Context [28910606] : variable [maven] => value = [null] > Context [28910606] : variable [maven.home] => value = > [C:\maven-1.1-beta3-20051210] > Context [28910606] : variable [user] => value = [null] > Context [28910606] : variable [user.home] => value = [C:\Documents and > Settings\mgubin] > Context [28910606] : variable [maven.home.local] => value = [C:\Documents and > Settings\mgubin/.maven] > Context [2
[jira] Updated: (MAVEN-1103) improve "goal not found" reporting
[ http://jira.codehaus.org/browse/MAVEN-1103?page=all ] Arnaud Heritier updated MAVEN-1103: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 type: Improvement (was: Bug) > improve "goal not found" reporting > -- > > Key: MAVEN-1103 > URL: http://jira.codehaus.org/browse/MAVEN-1103 > Project: Maven > Type: Improvement > Components: core > Versions: 1.0-rc1 > Reporter: Brett Porter > Priority: Minor > Fix For: 1.1-beta-4 > > > - goal not found should be an error message, not an exception when leaving > maven > - goals that are not found should be reported before any building is done -- 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-1726) CLONE -Add the possibility to use parent pom present in repo
[ http://jira.codehaus.org/browse/MAVEN-1726?page=all ]
Arnaud Heritier updated MAVEN-1726:
---
Fix Version: (was: 1.1-beta-3)
1.1-beta-4
> CLONE -Add the possibility to use parent pom present in repo
>
>
> Key: MAVEN-1726
> URL: http://jira.codehaus.org/browse/MAVEN-1726
> Project: Maven
> Type: New Feature
> Versions: 1.1-beta-3, 1.1-beta-1, 1.0.2, 1.1-beta-2
> Reporter: Manfred Mayer
> Priority: Minor
> Fix For: 1.1-beta-4
> Attachments: MAVEN-1726.txt
>
>
> For the extend tag, we can support http protocol, or another syntax like this
> ${repo}/aGroupId/poms/anArtifactId-version.pom. Personally,
> I prefer the second solution.
> With this features, users can share default pom parameter between all their
> projects, and it prepare the introduction of pom V4.
--
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-1692) improve error when 1.0.2 was in path but MAVEN_HOME is 1.1
[ http://jira.codehaus.org/browse/MAVEN-1692?page=all ] Arnaud Heritier updated MAVEN-1692: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > improve error when 1.0.2 was in path but MAVEN_HOME is 1.1 > -- > > Key: MAVEN-1692 > URL: http://jira.codehaus.org/browse/MAVEN-1692 > Project: Maven > Type: Improvement > Reporter: Brett Porter > Fix For: 1.1-beta-4 > > > currently, this errors out when trying to do XML things as the parser sys > properties are set. > At the start of the app, test the sys props, and if set, check they are > available. Give a helpful error message if not. -- 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-1127) decouple artifact type implementations from maven core
[ http://jira.codehaus.org/browse/MAVEN-1127?page=all ] Arnaud Heritier updated MAVEN-1127: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > decouple artifact type implementations from maven core > -- > > Key: MAVEN-1127 > URL: http://jira.codehaus.org/browse/MAVEN-1127 > Project: Maven > Type: New Feature > Components: core > Environment: all > Reporter: John Casey > Fix For: 1.1-beta-4 > Attachments: changes.patch, decoupled-artifact-types.patch, org.zip > > Original Estimate: 6 hours > Remaining: 6 hours > > This is a copy of the proposal email I send to the dev list > (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=13740): > While I find the plugin architecture of maven to be fantastic, I have run > into a somewhat serious barrier to my own plugin development > efforts: adding support for new artifacts requires some pretty significant > changes to the maven core, and results in a requirement that I maintain a > patch for each artifact type. > The Problem > > The concept of artifact types is intimately coupled with the rest of the > maven core implementation. There seems to be no real compelling reason for > this; each artifact type has a base set of operations which can be performed > against it (with high overlap between types: install, install-snapshot, > deploy, deploy-snapshot), and one or more plugins which are the primary > producers/consumers of it. While I would agree that certain artifact types > are fundamental to maven operation, it can also be stated that certain > plugins are similarly fundamental. Therefore, for these plugins, the concept > of decoupling via plugin architecture is flawed. In order to change the > plugin in any significant way, a change to the maven core may be required to > support changes to the artifact type. In addition, this inherently limits > plugin development by giving a hard-and-fast set of artifact types which can > be manipulated by maven. > The Solution > --- > Simply put, decouple artifact type implementations from the maven core. > Instead of having a concrete implementation specifying attributes about a > .jar, EJB, or .pom, factor out the common behavior (aforementioned > permutations of install and deploy) into an interface, called > ArtifactTypeHandler. Then, create concrete implementations of this interface > for each type. Finally, add a new dynamic type handler loader (factory class) > which will do the following: > 1. Pull the typename attribute from a dependency, or otherwise > arrive at the artifact type desired. > 2. Read the classpath resource META-INF/artifactTypes/typename; line 1 of > this file specifies the fully-qualified class name for the type handler. > 3. Instantiate this handler class, and return it as the implementation to use > in manipulating this artifact. > This is a variation on the JAR service discovery method specified in the > JDK1.3, and allows each _plugin_ to add an artifact type handler for its own > use. Unrecognized artifact types (i.e. the handler jar is not in the > classpath, and therefore the META-INF/artifactTypes/typename resource is not > present) can be ignored or throw an exception. > Justification > > Under this new architecture, the only artifact-related code in maven-core is > the ArtifactTypeHandlerFactory and the abstract [interface] > ArtifactTypeHandler. This frees maven up to be a general build tool, agnostic > of what type of artifacts it is handling. DLL's, C headers, configuration > files, etc. are all perfectly usable within the maven repository scheme. > Maven is only limited by the plugins available for it at this point, and > plugin development is not limited by the release cycle for maven-core. > I can produce a patch against maven to accomplish this, if there is adequate > interest... -- 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-456) unable to access remote repository via https
[ http://jira.codehaus.org/browse/MAVEN-456?page=all ]
Arnaud Heritier updated MAVEN-456:
--
Fix Version: (was: 1.1-beta-3)
1.1-beta-4
> unable to access remote repository via https
>
>
> Key: MAVEN-456
> URL: http://jira.codehaus.org/browse/MAVEN-456
> Project: Maven
> Type: Improvement
> Components: core
> Versions: 1.0-beta-10
> Reporter: Christoph Gruenwald
> Fix For: 1.1-beta-4
>
>
> the remote repository is only accessable through http; it is not possible to
> access it via https.
> i needed to modify two methods in the class httputils to get this running
> (see below).
>
> public static void getFile( String url,
> File destinationFile,
> boolean ignoreErrors,
> boolean useTimestamp,
> String proxyHost,
> String proxyPort,
> String proxyUserName,
> String proxyPassword )
> throws Exception
> {
> String[] s = parseUrl( url );
>
> // *** MODIFIED - BEGIN ***
>
> // need to create url with separated parameters
> String protocol = s[0];
> String username = s[1];
> String password = s[2];
> String hostname = s[3];
> String hostport = s[4];
> String parsedUrl = s[5];
>
> /*
> String username = s[0];
> String password = s[1];
> String parsedUrl = s[2];
>
> URL source = new URL( parsedUrl );
> */
>
> URL source = new URL(protocol, hostname, Integer.parseInt(hostport),
> parsedUrl);
>
> // *** MODIFIED - END ***
> //set the timestamp to the file date.
> long timestamp = 0;
> boolean hasTimestamp = false;
> if ( useTimestamp && destinationFile.exists() )
> {
> timestamp = destinationFile.lastModified();
> hasTimestamp = true;
> }
> //set proxy connection
> useProxyUser( proxyHost, proxyPort, proxyUserName, proxyPassword );
> //set up the URL connection
> URLConnection connection = source.openConnection();
>
> // *** MODIFIED - BEGIN ***
>
> // need to set javax.net.ssl.HostnameVerifier for
> javax.net.ssl.HttpsURLConnection, otherwise connection will be
> refused
> if (connection instanceof javax.net.ssl.HttpsURLConnection) {
> ( (javax.net.ssl.HttpsURLConnection) connection).setHostnameVerifier(
> new javax.net.ssl.HostnameVerifier() {
> public boolean verify(String hostname,
> javax.net.ssl.SSLSession session) {
> return true;
> }
> }
> );
> }
>
> // *** MODIFIED - END ***
>
> //modify the headers
> //NB: things like user authentication could go in here too.
> if ( useTimestamp && hasTimestamp )
> {
> connection.setIfModifiedSince( timestamp );
> }
> // prepare Java 1.1 style credentials
> if ( username != null || password != null )
> {
> String up = username + ":" + password;
> String encoding = null;
> // check to see if sun's Base64 encoder is available.
> try
> {
> sun.misc.BASE64Encoder encoder =
> (sun.misc.BASE64Encoder) Class.forName(
> "sun.misc.BASE64Encoder" ).newInstance();
> encoding = encoder.encode( up.getBytes() );
> }
> catch ( Exception ex )
> {
> // Do nothing, as for MavenSession we will never use
> // auth and we will eventually move over httpclient
> // in the commons.
> }
> connection.setRequestProperty( "Authorization", "Basic " + encoding );
> }
> ...
> }
>
> static String[] parseUrl( String url )
> {
> // *** MODIFIED - BEGIN ***
>
> // parsed url into more paramters - it must be created with separated
> parameters
> // this also fixes a bug caused in
> org.apache.maven.verifier.DependencyVerifier#getRemoteArtifact(Artifact)
> when a https-url is used
>
> /*
> String[] parsedUrl = new String[3];
> parsedUrl[0] = null;
> parsedUrl[1] = null;
> parsedUrl[2] = url;
> // We want to be able to deal with Basic Auth where the username
> // and password are part of the URL. An example of the URL string
> // we would like to be able to parse is like the following:
> //
> // http://username:[EMAIL PROTECTED]
> int i = url.indexOf( "@" );
> if ( i > 0 )
> {
> String s = url.substring( 7, i );
> int j = s.indexOf( ":" );
> parsedUrl[0] = s.substring( 0, j );
> parsedUrl[1] = s.substring( j + 1 );
> parsedUrl[2] = "http://"; + url.substring( i
[jira] Updated: (MAVEN-1644) Running Maven in a directory not containing a POM file always results in 'Build Successful'.
[ http://jira.codehaus.org/browse/MAVEN-1644?page=all ] Arnaud Heritier updated MAVEN-1644: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > Running Maven in a directory not containing a POM file always results in > 'Build Successful'. > > > Key: MAVEN-1644 > URL: http://jira.codehaus.org/browse/MAVEN-1644 > Project: Maven > Type: Improvement > Components: core > Versions: 1.1-beta-1, 1.0.2 > Environment: Not of importance. > Reporter: Davy Toch > Priority: Minor > Fix For: 1.1-beta-4 > > > In maven 1.0.2 and 1.1-beta-1, running 'maven' in a directory that doesn't > contain a POM file always results in 'Build Succesful'. > == > $.\maven.bat > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > BUILD SUCCESSFUL > Total time : 1 seconds > Finished at : vrijdag 8 juli 2005 13:32:35 CEST > == > This could be confusing for novice users of Maven and it would be better to > generate an error stating > that no POM file was found. -- 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-1663) should accept a list of goals
[ http://jira.codehaus.org/browse/MAVEN-1663?page=all ] Arnaud Heritier updated MAVEN-1663: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > should accept a list of goals > --- > > Key: MAVEN-1663 > URL: http://jira.codehaus.org/browse/MAVEN-1663 > Project: Maven > Type: Improvement > Components: model > Versions: 1.1-beta-1 > Reporter: Vincent Massol > Fix For: 1.1-beta-4 > > > It would be nice to allow specifying a list of goals in . This > would remove the need to have a maven.xml with the following kind of content: > > > -- 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-1686) be able to use sftp as a maven.repo.remote
[ http://jira.codehaus.org/browse/MAVEN-1686?page=all ] Arnaud Heritier updated MAVEN-1686: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > be able to use sftp as a maven.repo.remote > -- > > Key: MAVEN-1686 > URL: http://jira.codehaus.org/browse/MAVEN-1686 > Project: Maven > Type: Wish > Components: core > Reporter: Juan F. Codagnone > Fix For: 1.1-beta-4 > Attachments: MAVEN-1686.diff > > > It would be nice to be able to use sftp remote private repositories, as they > are easier to admin than https, with custom CA. -- 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-1738) Don't try to download SNAPSHOTs built in the same build
[ http://jira.codehaus.org/browse/MAVEN-1738?page=all ] Arnaud Heritier updated MAVEN-1738: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > Don't try to download SNAPSHOTs built in the same build > --- > > Key: MAVEN-1738 > URL: http://jira.codehaus.org/browse/MAVEN-1738 > Project: Maven > Type: Improvement > Components: core > Versions: 1.1-beta-2 > Reporter: Aaron Mulder > Fix For: 1.1-beta-4 > > > The Geronimo build includes like 50 modules. During normal development, > these are SHAPSHOTs. As of Maven 1.1-beta2, each SNAPSHOT is downloaded at > most once during the build, which cut down on a lot of extraneous downloads > (that is, say 40 of the 50 modules depend on geronimo-kernel, Maven will only > check to download it once). > However, since the geronimo build actually *builds* geronimo-kernel, there's > no need to check to download it at all. It would be great if, as a module is > built, if that module is a SNAPSHOT, it would be added to the "previously > checked snapshots" list, so no subsequent modules that depends on it would > attempt to download it at all. That would eliminate nearly all the download > activity during the Geronimo build, making it *substantially* faster. > Thanks. -- 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-1459) misleading error message
[ http://jira.codehaus.org/browse/MAVEN-1459?page=all ] Arnaud Heritier updated MAVEN-1459: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > misleading error message > > > Key: MAVEN-1459 > URL: http://jira.codehaus.org/browse/MAVEN-1459 > Project: Maven > Type: Improvement > Components: plugin manager > Reporter: Brett Porter > Fix For: 1.1-beta-4 > > > > > > > run this inside reactor (notice missing goal). > error message is "nested plugin housings" -- 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-1619) [PATCH] New tag
[ http://jira.codehaus.org/browse/MAVEN-1619?page=all ] Arnaud Heritier updated MAVEN-1619: --- Fix Version: (was: 1.1-beta-3) 1.1-beta-4 > [PATCH] New tag > --- > > Key: MAVEN-1619 > URL: http://jira.codehaus.org/browse/MAVEN-1619 > Project: Maven > Type: New Feature > Components: jelly/ant integration > Reporter: Felipe Leme > Fix For: 1.1-beta-4 > Attachments: GetTag.patch, MJT5-metadata.patch > > Original Estimate: 15 minutes > Remaining: 15 minutes > > We have a tag that can be used to add a new path element to an existing one > ( in advance if the path that is being added is not already in the other path. > One way would be to change the behaviour so it does not add a > path that it's already there; the other way would be to create a new tag > which could be used to get a path - for now, I'm providing a patch for such > new tag (which could be reused in other circunstances). > -- Felipe > PS: I'm assuming I don't have write access to the jelly-tags module, so the > patch... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1080) Maven download corrupted jar file into repository
[ http://jira.codehaus.org/browse/MAVEN-1080?page=all ] Arnaud Heritier updated MAVEN-1080: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > Maven download corrupted jar file into repository > - > > Key: MAVEN-1080 > URL: http://jira.codehaus.org/browse/MAVEN-1080 > Project: Maven > Type: Bug > Components: core > Versions: 1.0-rc1 > Reporter: Mesut Celik > Fix For: 1.1-beta-3 > > > When you break up downloading the jar files into repository while executing > some goal, Maven puts corrupted jar file into repository. > Solution is to copy the same jar to the correct folder in the repository > folder structure. -- 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-1500) nsis installer only works with nsis plugin v1.1
[ http://jira.codehaus.org/browse/MAVEN-1500?page=all ] Arnaud Heritier updated MAVEN-1500: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > nsis installer only works with nsis plugin v1.1 > --- > > Key: MAVEN-1500 > URL: http://jira.codehaus.org/browse/MAVEN-1500 > Project: Maven > Type: Bug > Components: installer > Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > The NSIS plugin 2.0-SNAPSHOT has been overhauled, and as such maven no longer > builds an installer successfully for itself. I had to downgrade to 1.1 for > the release (as I should, as that is what is bundled :) -- 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-1482) some genuine errors result in "fatal" errors
[ http://jira.codehaus.org/browse/MAVEN-1482?page=all ] Arnaud Heritier updated MAVEN-1482: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > some genuine errors result in "fatal" errors > > > Key: MAVEN-1482 > URL: http://jira.codehaus.org/browse/MAVEN-1482 > Project: Maven > Type: Bug > Components: core > Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > for example: extend a POM that doesn't exist. > Need to gracefully catch such exceptions and handle differently. -- 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-256) does not use the global session
[ http://jira.codehaus.org/browse/MAVEN-256?page=all ] Arnaud Heritier updated MAVEN-256: -- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > does not use the global session > > > Key: MAVEN-256 > URL: http://jira.codehaus.org/browse/MAVEN-256 > Project: Maven > Type: Bug > Components: core > Versions: 1.0-beta-8 > Reporter: Peter Lynch > Priority: Critical > Fix For: 1.1-beta-3 > Attachments: 1.0.2.patch, head.patch > > > The problem: > Basically there needs to be a way to call a goal from inside another goal and > have the called goal use the current session. > The result being no new session created and all already attained goals would > not > be called again by the called goal's prereqs attribute or nested > tags. > The only way to create a new session would be to use the tags or set > if an attribute is decided to > be the way to flag session creation. > Alternatively it was suggested a new tag be added called which > would always create a new session, and would be reverted to use > the current session. > Here is the thread from the mailing lists describing the problems and > soltuions. > - Original Message - > From: "Colin Sampaleanu" <[EMAIL PROTECTED]> > To: "Turbine Maven Users List" > Cc: "Turbine Maven Developers List" > Sent: Thursday, January 30, 2003 7:27 AM > Subject: Re: goals are broken, let's fix it > > bob mcwhirter wrote: > > > > >On Thu, 30 Jan 2003, Colin Sampaleanu wrote: > > > > > >>I think that there is currently a serious problem in maven and a number > > >>of plugins, in that 'attainGoal' is being used in various places (goals, > > >>preGoals, and postGoals) with the expectation that the goal being named > > >>to be attained will be part of the dependency graph of the main build > > >>itself, and will be attained only once. However, due to the way the > > >>werkz 'attainGoal' tag is implemented, there is no integration into the > > >>main maven dependency session, and each invocation of attainGoal with a > > >>specific goal will call that goal again including all its dependencies, > > >>becoming more of a subroutine call. At best, I would say it's confusing > > >>as hell, since the name 'attainGoal' implies something; certainly there > > >>is some code which is using the tag with the expectation that it is > > >>integrating into the dependency graph, and there is other code which is > > >>using it like a subroutine call. I would also suggest there need to be > > >>clearly named, different mechanisms, to handle both usage semantics. > > >> > > >> > > >Yah, this is a well-understood problem (at least by me, having written > > >werkz). > > > > > >Though, my non-scientific polling has resulted in me thinking that > > >most folks are now taking advantage of the fact that > > >doesn't participate in the global session. > > > > > >ie: > > > > > > > > > > > > > > > > > > > > >Where 'clean' wouldn't fire the 2nd time if we shared in the global > > >session. > > > > > >We noodled around with keeping the current syntax and semantics the > > >same but adding a session="true" attribute for folks needing new > > >semantics. > > > > > >Or, since so many other things have changed lately, retaining backwards > > >compatibility is less important, and we could certain make > > >behave has expected, and rename the current functionality to > > >or or somesuch. > > > > > >The biggest use-case we must accomodate is folks wanting to 'clean' > > >multple times and not have werkz think everything is still attained. > > > > > >Though, that could maybe be rememdied with something like: > > > > > > > > > > > > > > > > > > > > >That'd allow us to invalidate the werkz session and allow for rebuilds > > >without confusing werkz. > > > > > >IRC would probably be a glad place to hammer out the details. > > > > > (still cross-posting, as I think this has big implications for users as > > well as developers...) > > > > How are the IRC sessions typically arranged? i.e. when are you guys > > normally on?. My main issue with IRC is that unfortunately it is blocked > > for me during the day due to the firewall at work, although in the worst > > case I could probably ssh to my home machine and do a text mode client > > from there. Evenings wouldn't be a problem. > > > > My suggestion would be to have very clearly named mechanisms (either > > separate tags or attributes on the same tag) to attain goals and share > > the maven session, to attain goals and not share the maven session, and > > some other mechanism (such as calling a custom tag), that is encouraged > > as a means of code reuse/macro/subroutine, which some code is currently > > using attainGoal for today. I would favour making a maven (not > > necessarilly werkz) attainGoal by default share the session, given it's > > name, it'd be les
[jira] Updated: (MAVEN-1546) add maven.reactor.basedir property when the reactor starts to locate the project root
[ http://jira.codehaus.org/browse/MAVEN-1546?page=all ] Arnaud Heritier updated MAVEN-1546: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > add maven.reactor.basedir property when the reactor starts to locate the > project root > - > > Key: MAVEN-1546 > URL: http://jira.codehaus.org/browse/MAVEN-1546 > Project: Maven > Type: Bug > Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > add maven.reactor.basedir property when the reactor starts to locate the > project root -- 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-1466) install_repo.bat can require inconsistent quoting on the command line
[ http://jira.codehaus.org/browse/MAVEN-1466?page=all ] Arnaud Heritier updated MAVEN-1466: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > install_repo.bat can require inconsistent quoting on the command line > - > > Key: MAVEN-1466 > URL: http://jira.codehaus.org/browse/MAVEN-1466 > Project: Maven > Type: Bug > Components: documentation > Versions: 1.0 > Environment: Windows XP Professional SP 1 > Reporter: Albert Davidson Chou > Priority: Minor > Fix For: 1.1-beta-3 > > Original Estimate: 1 hour > Remaining: 1 hour > > The install_repo.bat script in version 1.0 builds up its argument word by > word and then puts double quotes around the value thereby built up wherever > it is used. However, this implementation makes using the script kind of > weird. On Windows I have to quote the command anyway if it contains spaces, > e.g., > "%MAVEN_HOME%\bin\install_repo.bat" > and I would expect to have to quote its argument for similar reasons. But as > it stands now, install_repo.bat _requires_ the following quoting syntax if > both MAVEN_HOME and HOME (or HOMEPATH) contain spaces: > "%MAVEN_HOME%\bin\install_repo.bat" %HOME%\.maven\repository > Note the inconsistency in quoting. > The Windows batch language doesn't treat quotes the way most shells do; the > quotes are literally part of the string rather than just a meta-character > that signifies that contained whitespace is literal rather than a command or > argument separator. The syntax %~1 can be used to produce a non-quoted and > fully-path-expanced version of whatever argument %1 was, at least in more > recent versions of Windows (2000, XP, 2003). No guarantees that this feature > is present in Windows 9x -- 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-1490) make plugin installation unique by artifactId
[ http://jira.codehaus.org/browse/MAVEN-1490?page=all ] Arnaud Heritier updated MAVEN-1490: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > make plugin installation unique by artifactId > - > > Key: MAVEN-1490 > URL: http://jira.codehaus.org/browse/MAVEN-1490 > Project: Maven > Type: Bug > Components: plugin manager > Versions: 1.0.1 > Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > currently, warning when multiple versions of a plugin are installed (based on > artifactId). > Instead: > if > 1 duplicated in installation, error > if > 1 duplicated in user directory, error > if 1 in install, 1 in user - honour user, not install -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1521) loading properties file via Ant property task does not work from maven.xml
[ http://jira.codehaus.org/browse/MAVEN-1521?page=all ] Arnaud Heritier updated MAVEN-1521: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > loading properties file via Ant property task does not work from maven.xml > -- > > Key: MAVEN-1521 > URL: http://jira.codehaus.org/browse/MAVEN-1521 > Project: Maven > Type: Bug > Components: jelly/ant integration > Versions: 1.0.1 > Environment: n/a > Reporter: Ian Springer > Fix For: 1.1-beta-3 > > > If I have the following line in maven.xml, either within a goal or outside of > any goals: > > where my.properties exists and is a valid Java props file, any properties > that are in my.properties end up with a value of "0" (yes, simply the zero > character) in Maven. -- 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-1656) Doco that explains the protocols required to allow maven.xml or any plugin.jelly to inject values into or retrieve values from another plugin
[ http://jira.codehaus.org/browse/MAVEN-1656?page=all ] Arnaud Heritier updated MAVEN-1656: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > Doco that explains the protocols required to allow maven.xml or any > plugin.jelly to inject values into or retrieve values from another plugin > - > > Key: MAVEN-1656 > URL: http://jira.codehaus.org/browse/MAVEN-1656 > Project: Maven > Type: Bug > Components: documentation > Versions: 1.1-beta-1 > Environment: All > Reporter: Andy Glick > Fix For: 1.1-beta-3 > > > Brett recently posted a suggestion to someone who asked how to access the > contents of "plugin a" from the context of "plugin b" or from maven.xml. > Brett stated that "plugin a" would have to be initialized before it could be > accessed, and that from what I could understand he recommended 1 or 2 ways to > do that: > 1) reference the artifact plugin's namespace in the project tag > 2) specify value="some.value"/> (I think that this is the proper syntax, but I'm not > sure :-). > Thierry Lach, who asked the question this time around, reported that using > the artifact namespace didn't work in his instance, but that setting the > scope to parent did. I'm hoping that we can put together a fairly > comprehensive explanation about what is going on here, and if that means > explaining why the project gave up on Jelly and switched to M2, then so be it. > See http://news.gmane.org/gmane.comp.jakarta.turbine.maven.user for the > postings > Given that during the last couple of months Vincent Massol recommended that > people use the now deprecated mechanism on the > mavenbook.org site (see Tip #2), I should think that there ought to be a > priority on documenting this issue in an obvious place, probably the FAQ, but > also on the Maven Jelly tags get and set entries. > If this is actually explicitly documented somewhere, I'm sorry to have wasted > anyone's time. I have seen several plugins that have successfully used the > artifact namespace tag, so there must be some way that people have learned > this. I simply wish that I knew how they had done so. ;-) > I'm willing to write the doco if someone would explain the details. -- 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-1629) Ugly error message when JDK 1.3 is set for JAVA_HOME
[ http://jira.codehaus.org/browse/MAVEN-1629?page=all ] Arnaud Heritier updated MAVEN-1629: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > Ugly error message when JDK 1.3 is set for JAVA_HOME > > > Key: MAVEN-1629 > URL: http://jira.codehaus.org/browse/MAVEN-1629 > Project: Maven > Type: Bug > Components: cli > Versions: 1.1-beta-1 > Environment: JAVA_HOME set to a 1.3 JDK > Reporter: dion gillard > Priority: Minor > Fix For: 1.1-beta-3 > > > Is there some nicer message that can be produced than this? > C:\source\wsad\workspace\Deployment>maven > Exception in thread "main" java.lang.UnsupportedClassVersionError: > org/apache/maven/cli/App (Unsupported major.minor version 48.0) > at java.lang.ClassLoader.defineClass0(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:488) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:243) > at java.net.URLClassLoader.access$100(URLClassLoader.java:51) > at java.net.URLClassLoader$1.run(URLClassLoader.java:190) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:183) > at java.lang.ClassLoader.loadClass(ClassLoader.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:250) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:190) > at com.werken.forehead.Forehead.setupEntry(Forehead.java:298) > at com.werken.forehead.Forehead.config(Forehead.java:256) > at com.werken.forehead.Forehead.config(Forehead.java:131) > at com.werken.forehead.Forehead.main(Forehead.java:579) -- 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-1492) use whole id, not artifact ID, for identifying plugins
[ http://jira.codehaus.org/browse/MAVEN-1492?page=all ] Arnaud Heritier updated MAVEN-1492: --- Fix Version: (was: 1.1-rc1) 1.1-beta-3 > use whole id, not artifact ID, for identifying plugins > -- > > Key: MAVEN-1492 > URL: http://jira.codehaus.org/browse/MAVEN-1492 > Project: Maven > Type: Bug > Components: plugin manager > Versions: 1.0.1 > Reporter: Brett Porter > Fix For: 1.1-beta-3 > > > currently we map artifactId's to plugins. This is not guaranteed to be > unique, so switch to mapping the groupId:artifactId combo. -- 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-1397) replace test plugin with surefire
[ http://jira.codehaus.org/browse/MAVEN-1397?page=all ] Arnaud Heritier updated MAVEN-1397: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > replace test plugin with surefire > - > > Key: MAVEN-1397 > URL: http://jira.codehaus.org/browse/MAVEN-1397 > Project: Maven > Type: Task > Reporter: Brett Porter > Assignee: Emmanuel Venisse > Priority: Blocker > Fix For: 1.1-beta-4 > > > avoid the need for forkmode=once by switching to the superior surefire plugin > for general testing. > Enhance the surefire mojo to provide the same output as junit so that the > test plugin remains backwards compatible. -- 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-1287) documentation ideas
[ http://jira.codehaus.org/browse/MAVEN-1287?page=all ] Arnaud Heritier updated MAVEN-1287: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > documentation ideas > --- > > Key: MAVEN-1287 > URL: http://jira.codehaus.org/browse/MAVEN-1287 > Project: Maven > Type: Task > Components: documentation > Versions: 1.0-rc3 > Reporter: Brett Porter > Priority: Blocker > Fix For: 1.1-beta-4 > > > - something like http://xstream.codehaus.org/versioning.html > - a key for the new xdoc symbols is needed (And must be optional). Maybe just > above the logo? > - refer to Pete Kazmier's previous work and perhaps torque for good examples: > tutorial, guides, howto, reference. -- 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-514) enhance resource filtering
[ http://jira.codehaus.org/browse/MAVEN-514?page=all ]
Arnaud Heritier updated MAVEN-514:
--
Fix Version: (was: 1.1-rc1)
1.1-beta-4
> enhance resource filtering
> --
>
> Key: MAVEN-514
> URL: http://jira.codehaus.org/browse/MAVEN-514
> Project: Maven
> Type: New Feature
> Components: model additions
> Reporter: Brett Porter
> Fix For: 1.1-beta-4
>
>
> Something discussed on the dev/user lists recently, and an initial
> implementation is in place. Here is my proposal from the list:
> I would like to propose a generic solution via the POM and whatever
> filter-enabled copying technique that is being used. Let me know what you
> think.
> Firstly, inside :
>
> ${basedir}/conf/${maven.username}.properties
> ${basedir}/conf/filters.properties
> ${basedir}/../common/filters.properties
>
> some.property
> some.value
>
>
> Or to go really crazy, have the above as a filterset, and wrap them up in a
> list of filtersets. Ant introduced this functionality, but personally I don't
> see the use for it as long as you keep your property names a little different.
> I also think build.properties, project.properties and
> driver/default.properties should be included by default when filtering is
> enabled.
> Now, each element can keep the true
> property to acknowledge it wants to be filtered.
> The reason to allow different files is that the purpose of filters is to be
> able to substitute varying values, so you may not want to hard code them into
> project.xml. And this configuration should be flexible enough to work without
> Ant if necessary.
>
> I'm happy to work on this once there is agreement - just opening this to
> track its progress.
--
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-1575) mavenSession.getAllGoalNames() should include goals from maven.xml
[ http://jira.codehaus.org/browse/MAVEN-1575?page=all ] Arnaud Heritier updated MAVEN-1575: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > mavenSession.getAllGoalNames() should include goals from maven.xml > -- > > Key: MAVEN-1575 > URL: http://jira.codehaus.org/browse/MAVEN-1575 > Project: Maven > Type: Improvement > Versions: 1.0.2 > Reporter: Michael Schuerig > Priority: Minor > Fix For: 1.1-beta-4 > > > Currently, mavenSession.getAllGoalNames() only gives a list of goals provided > by plugins; it should include goals defined in the project's maven.xml. > For one thing, this would improve the shell completion files generated by > maven-shell-plugin. > Michael -- 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-1147) tag should be able to inherit at least a subset of variables.
[ http://jira.codehaus.org/browse/MAVEN-1147?page=all ] Arnaud Heritier updated MAVEN-1147: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > tag should be able to inherit at least a subset of variables. > > > Key: MAVEN-1147 > URL: http://jira.codehaus.org/browse/MAVEN-1147 > Project: Maven > Type: Improvement > Components: jelly/ant integration > Versions: 1.0-rc1 > Environment: Windows 2000, J2SDK 1.4.2 > Reporter: Jan-Helge Bergesen > Fix For: 1.1-beta-4 > Attachments: maven-HEAD.patch, maven-jelly-tags-HEAD.patch, > maven-jelly-tags-MAVEN-1_0_1-BRANCH.patch > > > The maven:maven jelly tag should be able to inherit at least a subset of the > invoker's environment in order to do controlled override of properties set in > build/project properties. > Either by using something like or by context or > hierarchial naming convention of properties, ie: > my.prop1=a > my.prop2=b > your.prop1=c > ... > -- 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-1270) multiproject:clean fails due to dependencies in reactor set
[ http://jira.codehaus.org/browse/MAVEN-1270?page=all ] Arnaud Heritier updated MAVEN-1270: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > multiproject:clean fails due to dependencies in reactor set > --- > > Key: MAVEN-1270 > URL: http://jira.codehaus.org/browse/MAVEN-1270 > Project: Maven > Type: Improvement > Versions: 1.0-rc2 > Environment: RedHat 9.0. Sun JDK 1.4.2_01, Maven 1.0-rc2 > Reporter: Cameron Fieber > Priority: Minor > Fix For: 1.1-beta-4 > > > I appologize if this is already entered, but I was unable to find it > searching JIRA. This is the same as or similar to #MAVEN-443 which was > marked as can't reproduce. > If you have a multiproject build, you can't execute clean until all artifacts > in that build that depend on other artifacts in the build have been produced. > The ideal behaviour of multiproject:clean would be to either ignore > dependencies not needed for the clean task itself, or consider a dependency > satisfied if it is in the reactor set. > The case where this feature would be a particular benefit is when you have an > existing source tree, which has been built, and a new component is added. If > you do an update and pulling down the new component it has yet to be > compiled. You then can't do multiproject:clean on your existing tree because > the new dependencies to the new component can't be resolved. -- 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-1428) "Response content length not known"
[ http://jira.codehaus.org/browse/MAVEN-1428?page=all ] Arnaud Heritier updated MAVEN-1428: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > "Response content length not known" > --- > > Key: MAVEN-1428 > URL: http://jira.codehaus.org/browse/MAVEN-1428 > Project: Maven > Type: Improvement > Versions: 1.0.2 > Reporter: Brett Porter > Priority: Trivial > Fix For: 1.1-beta-4 > > > I'm getting this message with Maven 1.0 final at work (behind a proxy), but > it is then displaying the total size, so it is apparent that Content-Length > was specified. > The warning seems erroneous. -- 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-1267) create source distribution for Maven 1.0 as part of installer process
[ http://jira.codehaus.org/browse/MAVEN-1267?page=all ] Arnaud Heritier updated MAVEN-1267: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > create source distribution for Maven 1.0 as part of installer process > - > > Key: MAVEN-1267 > URL: http://jira.codehaus.org/browse/MAVEN-1267 > Project: Maven > Type: Task > Components: installer > Reporter: Brett Porter > Fix For: 1.1-beta-4 > > > currently build several binaries, but no source distribution -- 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-1452) Documentation: Windows Repository: Maven Repository, Roaming Profiles
[ http://jira.codehaus.org/browse/MAVEN-1452?page=all ] Arnaud Heritier updated MAVEN-1452: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > Documentation: Windows Repository: Maven Repository, Roaming Profiles > - > > Key: MAVEN-1452 > URL: http://jira.codehaus.org/browse/MAVEN-1452 > Project: Maven > Type: Improvement > Components: documentation > Environment: Windows > Reporter: Rolf Schmidiger > Fix For: 1.1-beta-4 > Attachments: roaming.patch > > > > Hi there > > > > The default behaviour of maven is to store the MAVEN_REPO under > > %USERPROFILE%\.maven\.. On Windows. > > > > This is all o.k. BUT: if you are logged on a Win-NT Domain and use > > Roaming Profiles the is a "little" problem: > > - the Maven Repo get copied all the time (due to roaming, and the > > location of the maven repo) > > - longer Login-times > > - Problems with the profile space (if limited) > > > > I don't think that the default location of the repo should be changed. > > But at least there should be a remark on > > http://maven.apache.org/start/install.html > > > > How to change the it (%USERPROFILE%\build.properties > > [maven.repo.local=C:/x/y/z] ->?) > CHECK: http://www.mail-archive.com/users@maven.apache.org/msg11654.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1106) remove poor uses of system.err/out in core and plugins
[ http://jira.codehaus.org/browse/MAVEN-1106?page=all ] Arnaud Heritier updated MAVEN-1106: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > remove poor uses of system.err/out in core and plugins > -- > > Key: MAVEN-1106 > URL: http://jira.codehaus.org/browse/MAVEN-1106 > Project: Maven > Type: Task > Versions: 1.0-rc1 > Reporter: Brett Porter > Priority: Minor > Fix For: 1.1-beta-4 > > > use logging mechanisms instead so destination of certain levels can be > controlled. -- 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-590) Distribute documentation with binaries
[ http://jira.codehaus.org/browse/MAVEN-590?page=all ] Arnaud Heritier updated MAVEN-590: -- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > Distribute documentation with binaries > -- > > Key: MAVEN-590 > URL: http://jira.codehaus.org/browse/MAVEN-590 > Project: Maven > Type: Improvement > Components: core > Versions: 1.0-rc3 > Reporter: Richard Atkins > Fix For: 1.1-beta-4 > > > The current maven distribution is almost unusable without a net connection. > There is not even a readme! > This needs to change before the final release, if only so new users will know > to set up a MAVEN_HOME, and run "maven -help" and "maven -g" to get help on > what the system can do. > Distributing the getting started guide is essential, and perhaps the plugin > documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1280) Support group ID in jar overrides
[ http://jira.codehaus.org/browse/MAVEN-1280?page=all ] Arnaud Heritier updated MAVEN-1280: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > Support group ID in jar overrides > - > > Key: MAVEN-1280 > URL: http://jira.codehaus.org/browse/MAVEN-1280 > Project: Maven > Type: New Feature > Components: core, documentation > Versions: 1.0-rc4 > Reporter: Archimedes Trajano > Fix For: 1.1-beta-4 > Attachments: ArtifactListBuilder-2.patch, ArtifactListBuilder-3.patch, > ArtifactListBuilder.patch, eclipse-classpath-jelly.patch, > project-descriptor.xml, user-guide.xml > > > Maven should add support for project local dependencies where a jar file is > stored in one of the lib folders in the project. > Currently there is undocumented support for it using maven.jar. however > the use of is deprecated and should be removed. > Another way I can think of is to use the properties project.path and > local.path > project.path == dependency relative to the location of the project.xml file. > This ensures that you are on the right file by using getParent of the > project.getFile() method. > local.path == dependency wherever on the system (just like maven.jar) > This would help speed up migration of ant projects to maven projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-126) Add a -logfile option
[ http://jira.codehaus.org/browse/MAVEN-126?page=all ] Arnaud Heritier updated MAVEN-126: -- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > Add a -logfile option > - > > Key: MAVEN-126 > URL: http://jira.codehaus.org/browse/MAVEN-126 > Project: Maven > Type: New Feature > Components: cli > Environment: Windows 98 > Reporter: Andrew Stevens > Assignee: Arnaud Heritier > Priority: Minor > Fix For: 1.1-beta-4 > Attachments: AntProjectBuilder.java.patch, JellyBuildListener.java.patch, > MAVEN126.patch, MavenConstants.java.patch > > > One of the options I find useful in Ant is '-logfile ', which > redirects the build's output to a given file. It would be nice if I could do > the same with Maven; I've not had much success trying to use Win98's command > line redirection or paging on Maven's output. -- 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-1384) Display something when a snapshot dependency is newer
[ http://jira.codehaus.org/browse/MAVEN-1384?page=all ]
Arnaud Heritier updated MAVEN-1384:
---
Fix Version: (was: 1.1-rc1)
1.1-beta-4
> Display something when a snapshot dependency is newer
> -
>
> Key: MAVEN-1384
> URL: http://jira.codehaus.org/browse/MAVEN-1384
> Project: Maven
> Type: Improvement
> Components: core
> Versions: 1.0
> Reporter: Julien Kirch
> Priority: Minor
> Fix For: 1.1-beta-4
>
>
> When a project dependency is a snasphot, a download.message is displayed,
> then when the external repository version is newer, the download starts, but
> when the local version is newer, no message is displayed and maven jump to
> the next dependency.
> It would be nice to have a message explaining why no download occured.
> ("Local version is ok" or something like this") because user doesn't
> understand why sometimes a download occurs and why sometimes not.
> In the same idea, I think that the download.message (Attempting to download
> ${1}.) is not well choosen because it's not really an attempt to download,
> but perhaps more a "Checking ${1}." or something like this sometimes followed
> by a download.
--
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-1514) Maven should be specific why it is downloading a dependency
[ http://jira.codehaus.org/browse/MAVEN-1514?page=all ] Arnaud Heritier updated MAVEN-1514: --- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > Maven should be specific why it is downloading a dependency > --- > > Key: MAVEN-1514 > URL: http://jira.codehaus.org/browse/MAVEN-1514 > Project: Maven > Type: Improvement > Components: core > Reporter: Brett Porter > Fix For: 1.1-beta-4 > Attachments: ConsoleDownloadMeter.patch, DependencyVerifier.patch, > messages_en.patch > > > Currently, it is impossible to tell why Maven is downloading a certain > dependency. The message should mention the project or plugin that the > dependency is related to so that it is clear. This is something that could > become quite confusing when troubleshooting under transitive dependencies as > well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-121) Checking of downloaded jars and other artifacts
[ http://jira.codehaus.org/browse/MAVEN-121?page=all ] Arnaud Heritier updated MAVEN-121: -- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > Checking of downloaded jars and other artifacts > --- > > Key: MAVEN-121 > URL: http://jira.codehaus.org/browse/MAVEN-121 > Project: Maven > Type: New Feature > Components: core > Versions: 1.1-beta-2 > Environment: all > Reporter: peter neubauer > Priority: Minor > Fix For: 1.1-beta-4 > > > Maven should check downloaded artifacts for integrety, especially .jar files, > since they can get corrupted by e.g. bad cvswrappers (no -kb) and other > things. Right now there is no way to now if a .jar is containing all > information once the filename exists in the local repository > /peter -- 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-122) FTP repository support
[ http://jira.codehaus.org/browse/MAVEN-122?page=all ] Arnaud Heritier updated MAVEN-122: -- Fix Version: (was: 1.1-rc1) 1.1-beta-4 > FTP repository support > -- > > Key: MAVEN-122 > URL: http://jira.codehaus.org/browse/MAVEN-122 > Project: Maven > Type: New Feature > Reporter: Carlo Conserva > Fix For: 1.1-beta-4 > Attachments: MavenFtp.zip, ftpdiff.txt > > > I've done some work to implement an FTP repository support in maven, > for dependency downloading and artifact deploying, > and I'd like my work to be included in the project if maven developers > consider it well made and useful. > In attachment I put all the necessary files to include my FTP patch in maven, > together with installation instructions and a description of the > modifications. > The code is tested with maven 1.0 beta 7. -- 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-1706) maven.src.dir != pom.build.sourceDirectory
[ http://jira.codehaus.org/browse/MAVEN-1706?page=all ]
Arnaud Heritier updated MAVEN-1706:
---
Fix Version: 1.1-beta-3
> maven.src.dir != pom.build.sourceDirectory
> --
>
> Key: MAVEN-1706
> URL: http://jira.codehaus.org/browse/MAVEN-1706
> Project: Maven
> Type: Bug
> Components: documentation, core
> Versions: 1.0.2
> Reporter: Peter Lynch
> Fix For: 1.1-beta-3
>
>
> Maven documentation states on
> http://maven.apache.org/reference/properties.html
> maven.src.dir The base directory for source code. DEPRECATED:
> Currently unused. Instead, use the element of the POM.
> ${basedir}/src
> Problem is that maven.src.dir != pom.build.sourceDirectory in practice.
> default of maven.src.dir property is ${basedir}/src. Most plugins project.xml
> and their dependent Jelly plugin code expect pom.build.sourceDirectory to
> point to src/java, ie. where your Java sources are located.
> Try setting sourceDirectory element in your java project's POM to 'src' and
> watch the various java/jar/junit plugin's croak if you have any other Java
> source files in any other location than src/java because they all will try to
> be compiled all at one. Another example: Grep for pom.build.sourceDirectory
> in your plugin cache and look at all the code that expects it to point to
> src/java, where you java sources live.
> The solution for existing projects is to ignore the documentation as written
> and make pom.build.sourceDirectory still point to src/java, then use
> maven.src.dir when they want the real root source directory. The
> documentation needs to be replaced on this front. Or replace the code in 10+
> standard plugins to not assume sourceDirectory element is pointing to Java
> home.
--
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-1733) Bootstrap failure: Unable to obtain goal [plugin:test], in maven:reactor
[ http://jira.codehaus.org/browse/MAVEN-1733?page=all ] Arnaud Heritier updated MAVEN-1733: --- Fix Version: 1.1-beta-3 > Bootstrap failure: Unable to obtain goal [plugin:test], in maven:reactor > > > Key: MAVEN-1733 > URL: http://jira.codehaus.org/browse/MAVEN-1733 > Project: Maven > Type: Bug > Versions: 1.1-beta-3 > Environment: Win XP, svn Checked out revision 355781. > Reporter: Jeff Jensen > Fix For: 1.1-beta-3 > Attachments: buildit.log > > > bootstrap consistently fails. Attached is log for my last run. > This is an interesting line from it: > [exec] Caused by: Unable to delete directory > C:\devroot\reference\maven\maven-1\plugins\trunk\genapp\src\plugin-test\nonStandardDirsTest\target > I completely deleted the svn dirs and got latest. The error above prior was > this: > [exec] Root cause > [exec] Unable to delete directory > C:\devroot\reference\maven\maven-1\plugins\trunk\genapp\src\plugin-test\mavenHomeLocalTemplateTest\target > And the run that failed before that one did not have an "unable to delete > dir". (I did about 6 or so bootstraps today, trying to get it to work) > They are on different plugins, such as Javadoc, Test Genapp. I have 3 of my > last logs, and a couple of them are the test genapp (not the middle run of > the 3). > I hope something helps here, and this isn't some silly chase. Thanks again > for looking into it. > I tried to determine some environment thing for me. > Oh, typing of environment, I am using JDK 1.5. Is that OK, or perhaps the > prob? -- 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-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on
[ http://jira.codehaus.org/browse/MAVEN-1677?page=all ]
Arnaud Heritier updated MAVEN-1677:
---
Fix Version: 1.1-beta-3
> "No directory specified for fileset" when debugging for
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
> Type: Bug
> Components: jelly/ant integration
> Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
> Reporter: Scott Lamb
> Priority: Minor
> Fix For: 1.1-beta-3
>
>
> I've been trying to debug problems by specifying an alternate
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can
> attach full exception info, the project I used, and the log4j config file I
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is
> not too helpful, though.
--
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-1696) Wrong basedir property in producess unusefull error message
[ http://jira.codehaus.org/browse/MAVEN-1696?page=all ]
Arnaud Heritier updated MAVEN-1696:
---
Fix Version: 1.1-beta-3
> Wrong basedir property in producess unusefull error message
>
>
> Key: MAVEN-1696
> URL: http://jira.codehaus.org/browse/MAVEN-1696
> Project: Maven
> Type: Bug
> Versions: 1.1-beta-1
> Environment: Linux, Maven 1.0.2/Maven 1.1-beta-1
> Reporter: Mykola Nikishov
> Fix For: 1.1-beta-3
> Attachments: extendbug.tar.gz, wrongextend.patch
>
>
> In one of my projects I've misspelt basedir property in such way:
> --- ok/project.xml 2005-08-05 00:55:49.0 +0300
> +++ bug/project.xml 2005-08-05 00:55:28.0 +0300
> @@ -1,6 +1,6 @@
>
>
> -${basedir}/../project.xml
> +{$basedir}/../project.xml
> 3
> and Maven reported about:
> File.. /home/mn/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly
> Element... maven:reactor
> Line.. 64
> Column 9
> Unknown error reading project
> for Maven 1.1-beta-1 and
> File.. /home/mn/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly
> Element... maven:reactor
> Line.. 64
> Column 9
> Parent POM is equal to the current POM
> for Maven 1.0.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] Updated: (MAVEN-1673) does not indicate failure
[ http://jira.codehaus.org/browse/MAVEN-1673?page=all ] Arnaud Heritier updated MAVEN-1673: --- Fix Version: 1.1-beta-3 > does not indicate failure > --- > > Key: MAVEN-1673 > URL: http://jira.codehaus.org/browse/MAVEN-1673 > Project: Maven > Type: Bug > Components: jelly/ant integration > Versions: 1.1-beta-1, 1.0.2 > Environment: OS X 10.4.2, JRE 1.4.2_07-215 > Reporter: Scott Lamb > Priority: Minor > Fix For: 1.1-beta-3 > Attachments: element-without-taskdef.tar.gz > > > maven does not error out when it encounters an ant element with no taskdef. > This is horribly confusing. ant produces a nice error message when run > directly. > This is likely to happen frequently on maven 1.1, since it no longer includes > many optional taskdefs. > In my tests, maven 1.0.2 completely ignores the unknown element. maven > 1.1-beta-1 prints out the literal element but still does nothing. > To reproduce with the attached testcase (not jUnit; sorry): > $ tar xvzf element-without-taskdef.tar.gz > $ cd element-without-taskdef > $ maven shouldfail > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-1 > build:start: > shouldfail: > BUILD SUCCESSFUL > Total time : 1 seconds > Finished at : Wednesday, August 24, 2005 4:01:53 PM PDT > vs ant: > $ ant shouldfail > Buildfile: build.xml > shouldfail: > BUILD FAILED > /private/tmp/element-without-taskdef/build.xml:8: Could not create task or > type of type: element-without-taskdef. > ... -- 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-1707) Malformed project.xml caueses unexpected error
[ http://jira.codehaus.org/browse/MAVEN-1707?page=all ] Arnaud Heritier updated MAVEN-1707: --- Fix Version: 1.1-beta-3 > Malformed project.xml caueses unexpected error > -- > > Key: MAVEN-1707 > URL: http://jira.codehaus.org/browse/MAVEN-1707 > Project: Maven > Type: Bug > Versions: 1.0.2 > Environment: Mac oS X 1.0.2, Java 1.4.2 > Reporter: Elliotte Rusty Harold > Fix For: 1.1-beta-3 > > > My project.xml is malformed. There is a ' character before the XMl > declaration that shouldn't be there. that is, it begins > ` > and it should begin > > Easy enough to fix (and for me to diagnose) but Maven gets really way more > confused by this than it should. > Even maven --info fails here. Maven should recognize this error for what it > is (malformed project.xml) and provide an appropriate error message to the > end user. Stack trace: > ~/projects/jaxen$ maven cobertura > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > Parse Fatal Error at line 1 column 1: Content is not allowed in prolog. > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at > org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown > Source) > at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown > Source) > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) > at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.commons.digester.Digester.parse(Digester.java:1527) > at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:203) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) > at > org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) > at org.apache.maven.MavenSession.initialize(MavenSession.java:172) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > 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 com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > org.apache.maven.MavenException: Error parsing project.xml > '/Users/elharo/Projects/Jaxen/project.xml' > at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:207) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) > at > org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) > at org.apache.maven.MavenSession.initialize(MavenSession.java:172) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > 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 com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > --- Nested Exception --- > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.commons.digester.Digester.parse(Digester.java:1527) > at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:203) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:143) > at org.apache.maven.MavenUtils.getProject(MavenUtils.java:122) > at > org.apache.maven.MavenSession.initializeRootProject(MavenSession.java:232) > at org.apache.maven.MavenSession.initialize(MavenSessio
[jira] Updated: (MAVEN-1711) Error reading POM
[ http://jira.codehaus.org/browse/MAVEN-1711?page=all ] Arnaud Heritier updated MAVEN-1711: --- Fix Version: 1.1-beta-3 > Error reading POM > - > > Key: MAVEN-1711 > URL: http://jira.codehaus.org/browse/MAVEN-1711 > Project: Maven > Type: Bug > Components: model > Versions: 1.1-beta-3 > Environment: 1.1 beta 3 2005-10-11 > Reporter: Arnaud Heritier > Fix For: 1.1-beta-3 > Attachments: MAVEN-1711-log.txt, project.xml > > > In some cases, maven breaks because it can't read a POM. > It occurs when there's for exemple a blank line just before the tag. > I already saw this error several times and it must occurs with all 1.1 > releases. > We must try to upgrade plexus-utils to see if it fixes the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVEN-1741) maven 1.1 fails to run commons-attributes in mutliproject mode on a war project
[ http://jira.codehaus.org/browse/MAVEN-1741?page=all ] Arnaud Heritier updated MAVEN-1741: --- Fix Version: 1.1-beta-3 > maven 1.1 fails to run commons-attributes in mutliproject mode on a war > project > --- > > Key: MAVEN-1741 > URL: http://jira.codehaus.org/browse/MAVEN-1741 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Reporter: nicolas de loof > Priority: Minor > Fix For: 1.1-beta-3 > Attachments: test_maven11_commons-attributes.zip > > > Attached zip contains a minimalist multiproject using commons-attributes that > demonstrates the bug. > - head (top level project) > - jar (minimalist jar project) : Sample.java has a "java.util.Date" attribute > - war (minimalist war project) : Sample.java has a "java.util.Date" attribute > When runing "maven war:install" on war project, attributes are generated as > expected. > When running from "head" project using "maven multiproject:install", > commons-attributes are > - generated as expected for the jar > - NOT generated in the war (no log from plugin) > I don't know if this is a maven, multiproject-plugin, war-plugin or > commons-attributes-plugin bug. > Please notice commons-attributes plugin uses a preGoal to automatically > register itself. -- 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-1675) Unable to extract maven-nsis-plugin-1.1.jar
[ http://jira.codehaus.org/browse/MAVEN-1675?page=all ] Arnaud Heritier updated MAVEN-1675: --- Fix Version: 1.1-beta-3 > Unable to extract maven-nsis-plugin-1.1.jar > --- > > Key: MAVEN-1675 > URL: http://jira.codehaus.org/browse/MAVEN-1675 > Project: Maven > Type: Bug > Components: plugin manager > Versions: 1.0.2 > Environment: Solaris 5.8, JDK 1.5.0 > Reporter: Alex Mayorga Adame > Fix For: 1.1-beta-3 > > > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > Initializing Plugins! > Set plugin source directory to /export1/eae/CIBOS/maven-1.0.2/plugins > Set unpacked plugin directory to /export1/CIBOS/maven-1.0.2/.maven/cache > Set user plugin directory to /export1/CIBOS/maven-1.0.2/.maven/plugins > Plugin cache will be regenerated > Unpacking maven-nsis-plugin-1.1.jar to directory --> > /export1/CIBOS/maven-1.0.2/.maven/cache/maven-nsis-plugin-1.1 > Invalidating plugin maven-nsis-plugin-1.1 > org.apache.maven.MavenException: Unable to extract plugin: > /export1/eae/CIBOS/maven-1.0.2/plugins/maven-nsis-plugin-1.1.jar > at > org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1075) > at > org.apache.maven.plugin.PluginManager.expandPluginFiles(PluginManager.java:321) > at > org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:288) > at > org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) > at org.apache.maven.MavenSession.initialize(MavenSession.java:171) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > --- Nested Exception --- > java.io.FileNotFoundException: > /export1/CIBOS/maven-1.0.2/.maven/cache/maven-nsis-plugin-1.1/META-INF/MANIFEST.MF > (No such file or directory) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:179) > at java.io.FileOutputStream.(FileOutputStream.java:131) > at org.apache.maven.util.Expand.extractFile(Expand.java:147) > at org.apache.maven.util.Expand.expandFile(Expand.java:85) > at org.apache.maven.util.Expand.execute(Expand.java:67) > at > org.apache.maven.plugin.PluginManager.unpackPlugin(PluginManager.java:1071) > at > org.apache.maven.plugin.PluginManager.expandPluginFiles(PluginManager.java:321) > at > org.apache.maven.plugin.PluginManager.initialize(PluginManager.java:288) > at > org.apache.maven.MavenSession.initializePluginManager(MavenSession.java:204) > at org.apache.maven.MavenSession.initialize(MavenSession.java:171) > at org.apache.maven.cli.App.doMain(App.java:475) > at org.apache.maven.cli.App.main(App.java:1239) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.werken.forehead.Forehead.run(Forehead.java:551) > at com.werken.forehead.Forehead.main(Forehead.java:581) > You have encountered an unknown error running Maven. Please help us to > correct > this problem by following these simple steps: > - read the Maven FAQ at http://maven.apache.org/faq.html > - run the same command again with the '-e' parameter, eg maven -e jar > - search the maven-user archives for the error at > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] > - post the output of maven -e to JIRA at > http://jira.codehaus.org/BrowseProject.jspa?id=10030 (you must sign up first) > - run 'maven --info' and post the output as the environment to the bug above > Final Memory: 0M/4M > Total time: 2 seconds > Finished at: Thu Aug 25 11:22:18 EDT 2005 > The user that is running maven is the owner of all folders, why is this > failing? -- 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-1679) maven 1.1-beta-1 chokes on XML Entities for non-US characters in project.xml
[ http://jira.codehaus.org/browse/MAVEN-1679?page=all ] Arnaud Heritier updated MAVEN-1679: --- Fix Version: 1.1-beta-3 > maven 1.1-beta-1 chokes on XML Entities for non-US characters in project.xml > > > Key: MAVEN-1679 > URL: http://jira.codehaus.org/browse/MAVEN-1679 > Project: Maven > Type: Bug > Components: model > Versions: 1.1-beta-1 > Reporter: Eirik Maus > Fix For: 1.1-beta-3 > > > To make project.xml readable across operating systems and parsers (even when > turned into html by the site plugin), we have used entities for non-US > characters in project xml. The XML parser used in maven 1.1 chokes on the > use of these entities (but not on the entity definition). This is very > unfortunate, as using entities for abbreviations and symbols is perfectly > legal Xml. > Example: won't work with 1.1: > > > > ]> > > 3 > ... > > > Marit Finne J&OSlash;rgensen > mfj > > > > > Example: fix for 1.1, with cross-system compatibility issues. > > > > ]> > > 3 > ... > > > Marit Finne Jørgensen > mfj > > > > > The XML parser chokes on the Usage of the XML Entity, inside 'Jørgensen', not > on the definition. -- 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-1751) "A cycle was detected" where no cycle can be found
[ http://jira.codehaus.org/browse/MAVEN-1751?page=all ] Arnaud Heritier updated MAVEN-1751: --- Fix Version: 1.1-beta-3 > "A cycle was detected" where no cycle can be found > -- > > Key: MAVEN-1751 > URL: http://jira.codehaus.org/browse/MAVEN-1751 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 > Reporter: Anders Heintz > Fix For: 1.1-beta-3 > Attachments: proj1_dependencies.xml, proj2_dependencies.xml, > proj3_dependencies.xml > > > I have a quite large multiproject project which I fail to build using Maven > 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and > excluded all but the most basic project, then added one at a time. When I > included my third project, the build fails with the message "A cycle was > detected". The dependencies for these tree projects (except external > dependencies) are: > Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. > Project 3 is a base "project" which contains common services and are used by > all other projects. > I'll attach the dependencies part of the three subprojects. > When I run the same goal (any multiproject goal, for example 'maven > -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: > Starting the reactor... > Our processing order: > webSelect Project 3 > webSelect Project 2 > webSelect Project 1 > When I tried commenting out all dependencies apart from the project mentioned > above, it still fails, it even fails when I remove Project 1's dependency to > Project 3. > What is even more confusing is when I replace Project 1 with another > subproject which have the same dependencies it works fine (which however, is > a ejb project instead of being a jar project which Project 1 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
