[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.:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
executions
execution
phaseprocess-sources/phase
goals
goaljavadoc/goal
/goals
/execution
/executions
/plugin
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasegenerate-sources/phase
configuration
sourceRoot${project.build.directory}/generated/java/sourceRoot
tasks
... some ant tasks
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
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
sourceRoot${project.build.directory}/generated-sources/main/java/sourceRoot
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: (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 developers 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: teamManagement developers/ contributors/ /teamManagement 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 developers 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 developerManagement 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: developerManagement developer idmsanchez/id nameMatt Sanchez/name email[EMAIL PROTECTED]/email urlhttp://priori.webify.local:9090/display/~msanchez/url timezone-6/timezone /developer developer idmperham/id nameMike Perham/name email[EMAIL PROTECTED]/email urlhttp://priori:9090/display/~mperham/url timezone-6/timezone /developer /developerManagement foo's pom.xml: developers developer idmperham/id roles roleOwner/role /roles /developer /developers 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-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-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 connectionscm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk/connection developerConnectionscm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk/developerConnection urlhttp://apollo.ucalgary.ca/websvncommons/listing.php?repname=pmgtamp;rev=0amp;sc=0amp;path=/trunk/url /scm ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId version2.0-beta-2-SNAPSHOT/version reportSets reportSet idchanges/id configuration displayFileDetailUrlhttp://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgtamp;rev=0amp;sc=0amp;path=/displayFileDetailUrl typerange/type range90/range /configuration reports reportchangelog/report reportfile-activity/report reportdev-activity/report /reports /reportSet /reportSets /plugin 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=pmgtsc=0path= but it should be like this: link = http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgtsc=0rev=0path=/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: (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-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: (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-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 codetrue/code 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] 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] 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] Created: (MAVEN-1752) Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.init(I)V
Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.init(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-testmaven __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT Plugin cache will be regenerated java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.init(I)V at org.apache.crimson.parser.Parser2.init(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-testmaven -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
[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:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
resourcesDir${basedir}/META-INF/resourcesDir
security
security-role id=SecurityRole_1131964323008
description/description
role-namemanager/role-name
/security-role
security-role id=SecurityRole_1131964323018
description/description
role-nameteller/role-name
/security-role
/security
/configuration
/plugin
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] 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: (MAVEN-1752) Strange bug that renders my maven useless: java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.init(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.init(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-testmaven __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT Plugin cache will be regenerated java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.init(I)V at org.apache.crimson.parser.Parser2.init(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-testmaven -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 =
[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
extend${repo}/aGroupId/poms/anArtifactId-version.pom/extend. 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
extend${repo}/aGroupId/poms/anArtifactId-version.pom/extend. 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.init(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.init(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-testmaven __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.1-beta-3-SNAPSHOT Plugin cache will be regenerated java.lang.NoSuchMethodError: org.apache.crimson.parser.SimpleHashtable.init(I)V at org.apache.crimson.parser.Parser2.init(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-testmaven -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
[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
extend${repo}/aGroupId/poms/anArtifactId-version.pom/extend. 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 typetypename/type 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 codejavax.net.ssl.HostnameVerifier/code for
codejavax.net.ssl.HttpsURLConnection/code, 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
codeorg.apache.maven.verifier.DependencyVerifier#getRemoteArtifact(Artifact)/code
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 + 1 );
}
*/
int pos0 = url.indexOf(://); int step0 = 3;
if (pos0 == -1) {
pos0 = url.indexOf(:/); step0
[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) defaultGoal 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 defaultGoal 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 defaultGoal. This would remove the need to have a maven.xml with the following kind of content: project goal name=myproject:dist prereqs=ejb:install,ejb:install-client,.../ /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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 ?xml version=1.0 encoding=iso-8859-1? project xmlns:j=jelly:core xmlns:d=deploy attainGoal name=jar:install/ /project 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 maven:getPath
[ 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 maven:getPath --- 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 (maven:addPath). That tag is great, but in some cases it's necessary to know in advance if the path that is being added is not already in the other path. One way would be to change the maven:addPath 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-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-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: property file=my.properties / 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 j:set target=plugin-name scope=parent var=some.plugin.var 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 dependency-handle 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-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 build:
filters
file${basedir}/conf/${maven.username}.properties/file
file${basedir}/conf/filters.properties/file
file${basedir}/../common/filters.properties/file
filter
tokensome.property/token
valuesome.value/value
/filter
/filters
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 resource/ element can keep the filteringtrue/filtering
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-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-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-1673) ant:element-without-taskdef does not indicate failure
[ http://jira.codehaus.org/browse/MAVEN-1673?page=all ] Arnaud Heritier updated MAVEN-1673: --- Fix Version: 1.1-beta-3 ant:element-without-taskdef 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: element-without-taskdef/element-without-taskdefBUILD 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 `?xml version=1.0 encoding=UTF-8? and it should begin ?xml version=1.0 encoding=UTF-8? 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(MavenSession.java:172) at
[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 project 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-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.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(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: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE project [ !ENTITY OSlash #248; !ENTITY CapitalOSlash #216; ] project pomVersion3/pomVersion ... developers developer nameMarit Finne JOSlash;rgensen/name idmfj/id /developer /developers /project Example: fix for 1.1, with cross-system compatibility issues. ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE project [ !ENTITY OSlash #248; !ENTITY CapitalOSlash #216; ] project pomVersion3/pomVersion ... developers developer nameMarit Finne Jørgensen/name idmfj/id /developer /developers /project 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
[jira] Updated: (MAVEN-1704) artifactId is used as groupId when the latest is not defined
[ http://jira.codehaus.org/browse/MAVEN-1704?page=all ] Arnaud Heritier updated MAVEN-1704: --- Fix Version: 1.1-beta-3 artifactId is used as groupId when the latest is not defined Key: MAVEN-1704 URL: http://jira.codehaus.org/browse/MAVEN-1704 Project: Maven Type: Bug Components: inheritance Versions: 1.1-beta-2 Reporter: Carlos Sanchez Fix For: 1.1-beta-3 artifactId is used as groupId when the latest is not defined (using extends at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven should complain. Which is really a problem is that if pom a extends pom b, and no groupId is defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, while in 1.1 artifactId of b is the chosen one. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1724) Provide a way for a maven1 build to upload to an m2 repository
[ http://jira.codehaus.org/browse/MAVEN-1724?page=all ] Arnaud Heritier updated MAVEN-1724: --- Fix Version: 1.1-beta-4 Provide a way for a maven1 build to upload to an m2 repository -- Key: MAVEN-1724 URL: http://jira.codehaus.org/browse/MAVEN-1724 Project: Maven Type: New Feature Versions: 1.1-beta-1 Reporter: Steve Loughran Fix For: 1.1-beta-4 I have to use other people's maven1 builds (e.g. axis) but use an m2 repository internally. there appears to be no automated way of doing an equivalent of jar:install to an m2 repository, without which it is really hard to integrate the two versions of maven. I know I can set up my repository list to include a legacy repository, but that doesnt help me share releases via a team repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1733) Bootstrap failure: Unable to obtain goal [plugin:test], in maven:reactor
[ http://jira.codehaus.org/browse/MAVEN-1733?page=all ] Arnaud Heritier closed MAVEN-1733: -- Assign To: Arnaud Heritier Resolution: Fixed I checked that to test all plugins we called always the clean goal before the test and never after (to avoid to delete a locked file or directory after a test - Windows OS only). I tested several times and I didn't reproduce it. 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 Assignee: Arnaud Heritier 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] Created: (MRELEASE-89) CLONE -release:prepare incorrectly Runtime.exec's m2 instead of mvn
CLONE -release:prepare incorrectly Runtime.exec's m2 instead of mvn --- Key: MRELEASE-89 URL: http://jira.codehaus.org/browse/MRELEASE-89 Project: Maven 2.x Release Plugin Type: Bug Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, release-plugin 2.0-beta-3-SNAPSHOT Reporter: Chad Boyd Assigned to: Brett Porter Priority: Blocker Fix For: 2.0-beta-4 I am using mvn because the m2 shell script clearly says THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD. Now, granted, I don't have $M2_HOME/bin in my path, I am using update-alternatives to select the m2 version to use, but if it did not fork(!) off a M2 process using the deprecated script name this wouldn't have happened. [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Can't run goal deploy at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:216) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Can't run goal deploy at org.apache.maven.plugins.release.PerformReleaseMojo.runGoals(PerformReleaseMojo.java:151) at org.apache.maven.plugins.release.PerformReleaseMojo.executeTask(PerformReleaseMojo.java:77) at org.apache.maven.plugins.release.AbstractReleaseMojo.execute(AbstractReleaseMojo.java:73) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:697) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:74) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:60) at org.apache.maven.plugins.release.PerformReleaseMojo.runGoals(PerformReleaseMojo.java:142) ... 20 more Caused by: java.io.IOException: java.io.IOException: m2: not found at java.lang.UNIXProcess.init(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) at java.lang.Runtime.exec(Runtime.java:591) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:692) ... 23 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1738) Don't try to download SNAPSHOTs built in the same build
[ http://jira.codehaus.org/browse/MAVEN-1738?page=comments#action_63355 ] Aaron Mulder commented on MAVEN-1738: - Oh, you're killing me! I was really hoping this would turn out to be a trivial fix (as module is built, add to already downloaded list). This would seriously speed up online Geronimo builds by like 95% since it has to download on the order of 50 modules during a full build, and there are few if any SNAPSHOTs outside of Geronimo itself. Is there any way this could be squeeze into 1.1-beta-3? Thanks, Aaron 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] Commented: (MAVEN-1738) Don't try to download SNAPSHOTs built in the same build
[ http://jira.codehaus.org/browse/MAVEN-1738?page=comments#action_63356 ] Lukas Theussl commented on MAVEN-1738: -- Sure, got a patch? 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] Commented: (MAVEN-1738) Don't try to download SNAPSHOTs built in the same build
[ http://jira.codehaus.org/browse/MAVEN-1738?page=comments#action_63357 ] Aaron Mulder commented on MAVEN-1738: - Can you point me to the parts of the 1.1 code where module build is finished and maintain list of previously attempted downloads happen? I'm completely unfamiliar with the Maven code. Thanks. 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] Commented: (MAVEN-1738) Don't try to download SNAPSHOTs built in the same build
[ http://jira.codehaus.org/browse/MAVEN-1738?page=comments#action_63358 ] Lukas Theussl commented on MAVEN-1738: -- So am I... That's really the problem we are having in maven 1 now: all the people who are actually familiar with the code are not interested in it anymore... 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] Created: (MPIR-43) Use the plugin testing harness and add tests for the project-info-report mojos
Use the plugin testing harness and add tests for the project-info-report mojos -- Key: MPIR-43 URL: http://jira.codehaus.org/browse/MPIR-43 Project: Maven 2.x Project Info Reports Plugin Type: Test Reporter: Edwin Punzalan Assigned to: 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] Commented: (MAVEN-1738) Don't try to download SNAPSHOTs built in the same build
[ http://jira.codehaus.org/browse/MAVEN-1738?page=comments#action_63359 ] Brett Porter commented on MAVEN-1738: - the m1 codebase isn't really that big, and if you stay away from the jelly and plugin manager monstrosity, pretty easy to understand. For this, I'd suggest ReactorTag should call a static method on DependencyVerifier to set the resolved ids after getting the list of sorted projects. 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] Closed: (MRELEASE-89) CLONE -release:prepare incorrectly Runtime.exec's m2 instead of mvn
[ http://jira.codehaus.org/browse/MRELEASE-89?page=all ] Brett Porter closed MRELEASE-89: Resolution: Duplicate Fix Version: (was: 2.0-beta-4) it is fixed in 2.0-beta-4, which is not yet released. I'm working on it now. CLONE -release:prepare incorrectly Runtime.exec's m2 instead of mvn --- Key: MRELEASE-89 URL: http://jira.codehaus.org/browse/MRELEASE-89 Project: Maven 2.x Release Plugin Type: Bug Environment: Linux/x86_64, FC4, jdk 1.5.0_06-b05, mvn 2.0.2, release-plugin 2.0-beta-3-SNAPSHOT Reporter: Chad Boyd Assignee: Brett Porter Priority: Blocker I am using mvn because the m2 shell script clearly says THE m2 COMMMAND IS DEPRECATED - PLEASE RUN mvn INSTEAD. Now, granted, I don't have $M2_HOME/bin in my path, I am using update-alternatives to select the m2 version to use, but if it did not fork(!) off a M2 process using the deprecated script name this wouldn't have happened. [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Can't run goal deploy at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:216) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Can't run goal deploy at org.apache.maven.plugins.release.PerformReleaseMojo.runGoals(PerformReleaseMojo.java:151) at org.apache.maven.plugins.release.PerformReleaseMojo.executeTask(PerformReleaseMojo.java:77) at org.apache.maven.plugins.release.AbstractReleaseMojo.execute(AbstractReleaseMojo.java:73) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:697) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:74) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:60) at org.apache.maven.plugins.release.PerformReleaseMojo.runGoals(PerformReleaseMojo.java:142) ... 20 more Caused by: java.io.IOException: java.io.IOException: m2: not found at java.lang.UNIXProcess.init(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) at java.lang.Runtime.exec(Runtime.java:591) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:692) ... 23 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2220) ${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized
[ http://jira.codehaus.org/browse/MNG-2220?page=comments#action_63361 ]
Brett Porter commented on MNG-2220:
---
what about ${project.*} ?
${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:
build
sourceDirectorysrc/sourceDirectory
testSourceDirectorysrc-test/testSourceDirectory
resources
resource
directory${pom.build.sourceDirectory}/directory
includes
include**/*.properties/include
/includes
/resource
/resources
testResources
testResource
directory${pom.build.testSourceDirectory}/directory
includes
include**/mockfiles//include
/includes
/testResource
/testResources
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: (MAVENUPLOAD-833) new jdtcore version 3.2
new jdtcore version 3.2 --- Key: MAVENUPLOAD-833 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-833 Project: maven-upload-requests Type: Task Reporter: Torsten Curdt Assigned to: Carlos Sanchez please update to this latest stable release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-833) new jdtcore version 3.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-833?page=all ] Torsten Curdt closed MAVENUPLOAD-833: - Resolution: Incomplete could not modify after clone new jdtcore version 3.2 --- Key: MAVENUPLOAD-833 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-833 Project: maven-upload-requests Type: Task Reporter: Torsten Curdt Assignee: Carlos Sanchez please update to this latest stable release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-834) Please update to the latest stable version.
Please update to the latest stable version. --- Key: MAVENUPLOAD-834 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-834 Project: maven-upload-requests Type: Task Reporter: Torsten Curdt http://vafer.org/pub/jdtcore-bundle.jar http://eclipse.org Please update to the latest stable version (3.2M6) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-2223) Interpolation in resources section appears not to work correctly
Interpolation in resources section appears not to work correctly
Key: MNG-2223
URL: http://jira.codehaus.org/browse/MNG-2223
Project: Maven 2
Type: Bug
Versions: 2.0.4
Reporter: Jason van Zyl
This is captured by it0091 and reported by David Kulp. This might be duplicated
because I'm sure I put this in JIRA.
This may specifically be a property which is a boolean value, or a general
interpolation problem in the resources section.
project
modelVersion4.0.0/modelVersion
groupIdorg.apache.maven.it/groupId
artifactIdmaven-core-it0090/artifactId
version1.0/version
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
typejar/type
scopetest/scope
/dependency
/dependencies
properties
filter.resourcestrue/filter.resources
namejason/name
/properties
build
resources
resource
directorysrc/main/resources/directory
filtering${filter.resources}/filtering
/resource
/resources
/build
/project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
