[jira] Created: (MPANT-20) Allow URL substitutions in generated build.xml files
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPANT-20 Here is an overview of the issue: - Key: MPANT-20 Summary: Allow URL substitutions in generated build.xml files Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-ant-plugin Assignee: Arnaud HERITIER Reporter: Craig McClanahan Created: Wed, 1 Dec 2004 1:34 AM Updated: Wed, 1 Dec 2004 1:34 AM Environment: Java Description: Issue MPANT-7 contemplates improvements to the generated build.xml file that is produced by this plugin, but it does not deal with a use case that I am facing. In various Jakarta Commons packages that I participate in, we like to cater to users who like Ant as well as those who like Maven as their build tool. To accomodate the Ant users, we have a developer periodically generate the build.xml file (using this plugin) and check it in to our CVS repository. For the most part, this approach is functional -- although I'll quibble about the fact that "ant clean dist" cleans out the downloaded dependencies, so my nightly builds of Commons packages always have to download them again, but that's a different issue :-). However, this situation fails with dependencies that cannot be publicly posted on a Maven repository. In particular, this currently affects Commons Email (which needs JavaMail and JAF jars) and Commons Chain (which needs JavaServer Faces API jars), which cannot be posted in a repository due to license restrictions. The changes for MPANT-7 seem to help if the same person is both generating the build.xml file and executing it (with overrides in your local project properties). But it doesn't help when someone *else* is going to download and execute the build.xml file. I suggest changes to the generated build.xml file along the following lines: * Add a '' element at the top of the generated script, to pick up local property overrides. * For each dependency where you are going to generate a command, create an Ant property that defines the default URL from which to retrieve that dependency. * In the actual tasks, use the Ant property instead of a hard coded URL based on the default repository. In this way, I can point at any particular repository -- or, for that matter, to any local file if I create a file: URL -- for any given dependency. This allows users of the generated build.xml file to point at their own copies of non-redistributable JAR files, without impacting the generated build.xml file itself (which is obviously preferable to hand editing the generated file each time it is recreated). - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPXDOC-130) CVS Usage Page is blank when using Subversion scm.
The following issue has been updated: Updater: Evrim ULU (mailto:[EMAIL PROTECTED]) Date: Tue, 30 Nov 2004 9:57 PM Comment: Ive forgotten a dot char in the output. Hope this night will end:( Changes: Attachment changed to svnv2.patch - For a full history of the issue, see: http://jira.codehaus.org/browse/MPXDOC-130?page=history - View the issue: http://jira.codehaus.org/browse/MPXDOC-130 Here is an overview of the issue: - Key: MPXDOC-130 Summary: CVS Usage Page is blank when using Subversion scm. Type: Improvement Status: Resolved Priority: Major Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Fix Fors: 1.9 Assignee: Arnaud HERITIER Reporter: Evrim ULU Created: Tue, 30 Nov 2004 10:57 AM Updated: Tue, 30 Nov 2004 9:57 PM Environment: maven-xdoc-1.8 Description: Maven-xdoc-plugin generates mostly empty page if project uses Subversion scm. Although maven now can not checkout projects from svn repos, cvs-usage.xml template must generate a command line checkout instructions. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (MPXDOC-130) CVS Usage Page is blank when using Subversion scm.
Message: The following issue has been resolved as FIXED. Resolver: Evrim ULU Date: Tue, 30 Nov 2004 9:52 PM svn.patch attachment seems to resolve the issue. - View the issue: http://jira.codehaus.org/browse/MPXDOC-130 Here is an overview of the issue: - Key: MPXDOC-130 Summary: CVS Usage Page is blank when using Subversion scm. Type: Improvement Status: Resolved Priority: Major Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Fix Fors: 1.9 Assignee: Arnaud HERITIER Reporter: Evrim ULU Created: Tue, 30 Nov 2004 10:57 AM Updated: Tue, 30 Nov 2004 9:52 PM Environment: maven-xdoc-1.8 Description: Maven-xdoc-plugin generates mostly empty page if project uses Subversion scm. Although maven now can not checkout projects from svn repos, cvs-usage.xml template must generate a command line checkout instructions. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPXDOC-130) CVS Usage Page is blank when using Subversion scm.
The following issue has been updated: Updater: Evrim ULU (mailto:[EMAIL PROTECTED]) Date: Tue, 30 Nov 2004 9:51 PM Comment: Attached patch parses svn string from pom and inserts it into generated cvs-usage.html. It does not implement a parser for string because i am bored that jelly does not have a regexp token replacer. As I have discussed this patch must be updated according to new scm structure. I will be easier than my hacking effort. Changes: Attachment changed to svn.patch - For a full history of the issue, see: http://jira.codehaus.org/browse/MPXDOC-130?page=history - View the issue: http://jira.codehaus.org/browse/MPXDOC-130 Here is an overview of the issue: - Key: MPXDOC-130 Summary: CVS Usage Page is blank when using Subversion scm. Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Assignee: Arnaud HERITIER Reporter: Evrim ULU Created: Tue, 30 Nov 2004 10:57 AM Updated: Tue, 30 Nov 2004 9:51 PM Environment: maven-xdoc-1.8 Description: Maven-xdoc-plugin generates mostly empty page if project uses Subversion scm. Although maven now can not checkout projects from svn repos, cvs-usage.xml template must generate a command line checkout instructions. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-130) CVS Usage Page is blank when using Subversion scm.
The following comment has been added to this issue: Author: Evrim ULU Created: Tue, 30 Nov 2004 7:37 PM Body: I was using maven 1.0 and after downloading CVS snapshot, i realized that all maven-scm package is restructured. After my observations, there is no method named getSvnRoot() inside maven versions 1.0 and 1.0.1. Although situation seems to push me to wait for final-restructured-scm release, a quick hack can be done using jelly. Ive seen that scm:parse-connection goal parses svn connection string into tokens. I may try to copy-paste code into xdoc/plugin.jelly and make maven.scm.svn variable available to velocity template. If i move it to xdoc plugin, xdoc can parse the connection string but it obviously results code duplication. Anyway, this will be quick hack, not a real solution. After new maven scm release, problem will be solved simply by calling scm-provider-specific methods ie getCvsRoot(), getSvnRoot(). - View this comment: http://jira.codehaus.org/browse/MPXDOC-130?page=comments#action_27321 - View the issue: http://jira.codehaus.org/browse/MPXDOC-130 Here is an overview of the issue: - Key: MPXDOC-130 Summary: CVS Usage Page is blank when using Subversion scm. Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Assignee: Arnaud HERITIER Reporter: Evrim ULU Created: Tue, 30 Nov 2004 10:57 AM Updated: Tue, 30 Nov 2004 7:37 PM Environment: maven-xdoc-1.8 Description: Maven-xdoc-plugin generates mostly empty page if project uses Subversion scm. Although maven now can not checkout projects from svn repos, cvs-usage.xml template must generate a command line checkout instructions. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Quoting Michal Maczka <[EMAIL PROTECTED]>: > I imagined that there will be always one parser in m2 for all possible > released pom v4 variants and it will hide all the complexivity > related to changes in POM structure. Exactly like it used to be for m1 > where for example we had dual support > for "id" and "groupId"/"artifactId' tags in dependency. > So if we will have something like maven2-model-v4-1.0.2.jar - it will > contain the only parser which users/developers want to use > to parse all known variants of pom v4. Once we will have pom v403 we > will release maven2-model-v4-1.0.3.jar > which support all previous versions and this new version. Isn't it > simple enough? Sorry if I confused the issue. As Jason said, if there are just additions, converters won't be needed and upgrading a JAR will just work. So exactly what you are saying is how it works currently. However, the artifact ID would be maven-model-4.0.0, maven-model-4.0.1, etc. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
On Wed, 2004-12-01 at 00:27, Michal Maczka wrote: > Brett Porter wrote: > I am just trying to propose something simpler as I am afraid that there > will be way too many converters and parsers. The whole point in trying to stabilize the v4 POM is so that there will not be a proliferation of parsers and converters. For the v4.x there will only ever be additions. Period. If we much something up then we can replace the bad elements with something better but leave the mistakes and deprecate them over years. That being the case there won't be any converters because it will all be additions. And because we will only be dealing with additions any subsequent versions of the generate model tools will know how to deal with past versions. Moving from v3 -> v4 is the only real chore we have to deal with. It will be simple because we're only going to do additions. And we can only do additions to the model as it's the only way we're going to have long-term stability. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Brett Porter wrote: Next question is what we can really do with converters between major versions of POMs: e.g. between v3 and v4 and where and how such converter will be used? I believe Trygvis has already implemented one for continuum. Correct, it is only partially automated, but it can warn on ignored info, fail on missing info. It can easily handle the different names in scm and connection, for example. As far I know Trygvis' tool converts poms in the repository. The biggest problem here is not that pom structure is different but that in case of m1 poms were splitted into 3 files (project.xml, project.properties, maven.xml) And we will just have one of them (project.xml) in the repository. Michal -- Ponad 400 tysiecy facetow czeka na Ciebie http://link.interia.pl/f183a - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Brett Porter wrote: [...] It's been decided writing small converters (and if the changes are compatible, they should be trivial to write) is better than trying to get the model to do some form of inheritence. Minor versions might introduce deprecations on elements, for example - which makes the model different. Is there any reason where this is actually going to cause you a problem? I am just trying to propose something simpler as I am afraid that there will be way too many converters and parsers. It could be that I don't get correctly what is the responsibility of "converter" in that solution. Say that the latest POM version supported by m2 is v402 - how many packages with different model versions and how many converters we will need to distribute to support v400, v401? I imagined that there will be always one parser in m2 for all possible released pom v4 variants and it will hide all the complexivity related to changes in POM structure. Exactly like it used to be for m1 where for example we had dual support for "id" and "groupId"/"artifactId' tags in dependency. So if we will have something like maven2-model-v4-1.0.2.jar - it will contain the only parser which users/developers want to use to parse all known variants of pom v4. Once we will have pom v403 we will release maven2-model-v4-1.0.3.jar which support all previous versions and this new version. Isn't it simple enough? Michal -- Nudzisz sie? Zagraj sobie! >>> http://link.interia.pl/f183d - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
Next question is what we can really do with converters between major versions of POMs: e.g. between v3 and v4 and where and how such converter will be used? I believe Trygvis has already implemented one for continuum. Correct, it is only partially automated, but it can warn on ignored info, fail on missing info. It can easily handle the different names in scm and connection, for example. It's been decided writing small converters (and if the changes are compatible, they should be trivial to write) is better than trying to get the model to do some form of inheritence. Minor versions might introduce deprecations on elements, for example - which makes the model different. Is there any reason where this is actually going to cause you a problem? Haven't we been planning to use new way of declaring project inheritance in 1.1 with help of groupId and artifactId versions tags (like in m)? Yes, but optionally. will still be there. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-14) Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory.
The following issue has been updated: Updater: Alexey Dashkevich (mailto:[EMAIL PROTECTED]) Date: Tue, 30 Nov 2004 1:46 PM Changes: Attachment changed to aspectj-patch-dash-20041130.zip - For a full history of the issue, see: http://jira.codehaus.org/browse/MPASPECTJ-14?page=history - View the issue: http://jira.codehaus.org/browse/MPASPECTJ-14 Here is an overview of the issue: - Key: MPASPECTJ-14 Summary: Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory. Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-aspectj-plugin Versions: 3.2 Assignee: Reporter: Alexey Dashkevich Created: Tue, 30 Nov 2004 1:45 PM Updated: Tue, 30 Nov 2004 1:46 PM Description: Some days ago I have started to use aspectj plugin for compilation aspects. I use aspects only for tests. I have following structure in project: -src | aspectj - aspect sources | java - application sources | test - test sources I have an "lst" file where defined what files should be compiled with aspects e.g.: com/toplinkmapping/UserRoleAspect.java ../java/com/toplinkmapping/UserRole.java I want compile only files that defined in "lst" file and place classes into test-classes folder. In project.properties I have defined following properties: maven.aspectj.source=1.4 maven.aspectj.argfiles=src/aspectj/aspects.lst But when I have executed aspectj:compile I have error because this task try to compile files from aspects.lst file and then from src/java folder. And error occur because in aspects.lst defined files from java source folder. I have resolved this problem in my maven.xml by following way: So as you can see I have overwrite "maven.compile.src.set" path that not so good. I think it will be good if will be introduced new property like "maven.aspectj.src.argfilesOnly" that if true then only sources that defined in argument files will be weaved. And following changes in plugin script are needed e.g.: from to I have attached patch and test case for it. Please, take a look at them. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPASPECTJ-14) Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory.
The following issue has been updated: Updater: Alexey Dashkevich (mailto:[EMAIL PROTECTED]) Date: Tue, 30 Nov 2004 1:47 PM Changes: Attachment changed to aspectj-test-case-dash-20041130.zip - For a full history of the issue, see: http://jira.codehaus.org/browse/MPASPECTJ-14?page=history - View the issue: http://jira.codehaus.org/browse/MPASPECTJ-14 Here is an overview of the issue: - Key: MPASPECTJ-14 Summary: Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory. Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-aspectj-plugin Versions: 3.2 Assignee: Reporter: Alexey Dashkevich Created: Tue, 30 Nov 2004 1:45 PM Updated: Tue, 30 Nov 2004 1:47 PM Description: Some days ago I have started to use aspectj plugin for compilation aspects. I use aspects only for tests. I have following structure in project: -src | aspectj - aspect sources | java - application sources | test - test sources I have an "lst" file where defined what files should be compiled with aspects e.g.: com/toplinkmapping/UserRoleAspect.java ../java/com/toplinkmapping/UserRole.java I want compile only files that defined in "lst" file and place classes into test-classes folder. In project.properties I have defined following properties: maven.aspectj.source=1.4 maven.aspectj.argfiles=src/aspectj/aspects.lst But when I have executed aspectj:compile I have error because this task try to compile files from aspects.lst file and then from src/java folder. And error occur because in aspects.lst defined files from java source folder. I have resolved this problem in my maven.xml by following way: So as you can see I have overwrite "maven.compile.src.set" path that not so good. I think it will be good if will be introduced new property like "maven.aspectj.src.argfilesOnly" that if true then only sources that defined in argument files will be weaved. And following changes in plugin script are needed e.g.: from to I have attached patch and test case for it. Please, take a look at them. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPASPECTJ-14) Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory.
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPASPECTJ-14 Here is an overview of the issue: - Key: MPASPECTJ-14 Summary: Unable to weave only sources defined in argument files. Error during compilation if argument file contains file from sourceDirectory. Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-aspectj-plugin Versions: 3.2 Assignee: Reporter: Alexey Dashkevich Created: Tue, 30 Nov 2004 1:45 PM Updated: Tue, 30 Nov 2004 1:45 PM Description: Some days ago I have started to use aspectj plugin for compilation aspects. I use aspects only for tests. I have following structure in project: -src | aspectj - aspect sources | java - application sources | test - test sources I have an "lst" file where defined what files should be compiled with aspects e.g.: com/toplinkmapping/UserRoleAspect.java ../java/com/toplinkmapping/UserRole.java I want compile only files that defined in "lst" file and place classes into test-classes folder. In project.properties I have defined following properties: maven.aspectj.source=1.4 maven.aspectj.argfiles=src/aspectj/aspects.lst But when I have executed aspectj:compile I have error because this task try to compile files from aspects.lst file and then from src/java folder. And error occur because in aspects.lst defined files from java source folder. I have resolved this problem in my maven.xml by following way: So as you can see I have overwrite "maven.compile.src.set" path that not so good. I think it will be good if will be introduced new property like "maven.aspectj.src.argfilesOnly" that if true then only sources that defined in argument files will be weaved. And following changes in plugin script are needed e.g.: from to I have attached patch and test case for it. Please, take a look at them. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible meeting of the minds in Europe
After the 15th February ??? I think it is possible for me in January or February. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1521) loading properties file via Ant property task does not work from maven.xml
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MAVEN-1521 Here is an overview of the issue: - Key: MAVEN-1521 Summary: loading properties file via Ant property task does not work from maven.xml Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: jelly/ant integration Versions: 1.0.1 Assignee: Reporter: Ian Springer Created: Tue, 30 Nov 2004 12:44 PM Updated: Tue, 30 Nov 2004 12:44 PM Environment: n/a Description: If I have the following line in maven.xml, either within a goal or outside of any goals: where my.properties exists and is a valid Java props file, any properties that are in my.properties end up with a value of "0" (yes, simply the zero character) in Maven. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-264) eclipse jdtcore update
The following comment has been added to this issue: Author: Torsten Curdt Created: Tue, 30 Nov 2004 12:12 PM Body: Waiting for feedback. - View this comment: http://jira.codehaus.org/browse/MAVENUPLOAD-264?page=comments#action_27299 - View the issue: http://jira.codehaus.org/browse/MAVENUPLOAD-264 Here is an overview of the issue: - Key: MAVENUPLOAD-264 Summary: eclipse jdtcore update Type: Task Status: Reopened Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-upload-requests Assignee: Carlos Sanchez Reporter: Torsten Curdt Created: Sun, 21 Nov 2004 8:25 PM Updated: Tue, 30 Nov 2004 12:12 PM Description: http://eclipse.org Please update!! - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPXDOC-130) CVS Usage Page is blank when using Subversion scm.
The following comment has been added to this issue: Author: Evrim ULU Created: Tue, 30 Nov 2004 12:08 PM Body: I have tried to add necessary output to velocity macro cvs-usage.xml file. But it seems the following macros are not parsed if scm is svn in project.xml. #set ($conn = $repository.getCvsRoot($repository.connection, '')) #set ($module = $repository.getCvsModule($repository.connection)) I couldn't find the repository class in maven repository. If somebody shows me the code, i may alter it to parse it. Anyway, i'll continue to examine the code. - View this comment: http://jira.codehaus.org/browse/MPXDOC-130?page=comments#action_27298 - View the issue: http://jira.codehaus.org/browse/MPXDOC-130 Here is an overview of the issue: - Key: MPXDOC-130 Summary: CVS Usage Page is blank when using Subversion scm. Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Assignee: Arnaud HERITIER Reporter: Evrim ULU Created: Tue, 30 Nov 2004 10:57 AM Updated: Tue, 30 Nov 2004 12:08 PM Environment: maven-xdoc-1.8 Description: Maven-xdoc-plugin generates mostly empty page if project uses Subversion scm. Although maven now can not checkout projects from svn repos, cvs-usage.xml template must generate a command line checkout instructions. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-267) Please upload jbpm 2.0 to ibiblio
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MAVENUPLOAD-267 Here is an overview of the issue: - Key: MAVENUPLOAD-267 Summary: Please upload jbpm 2.0 to ibiblio Type: Task Status: Unassigned Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-upload-requests Assignee: Reporter: Yujin Kim Created: Tue, 30 Nov 2004 11:15 AM Updated: Tue, 30 Nov 2004 11:15 AM Description: Jbpm is a BPM framework and is now part of Jboss alliance http://sourceforge.net/project/showfiles.php?group_id=70542&package_id=117680 thanks - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPXDOC-130) CVS Usage Page is blank when using Subversion scm.
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPXDOC-130 Here is an overview of the issue: - Key: MPXDOC-130 Summary: CVS Usage Page is blank when using Subversion scm. Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-xdoc-plugin Assignee: Arnaud HERITIER Reporter: Evrim ULU Created: Tue, 30 Nov 2004 10:57 AM Updated: Tue, 30 Nov 2004 10:57 AM Environment: maven-xdoc-1.8 Description: Maven-xdoc-plugin generates mostly empty page if project uses Subversion scm. Although maven now can not checkout projects from svn repos, cvs-usage.xml template must generate a command line checkout instructions. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OT: Developers in south america
Hi Are there any developers in south america? Came to mi mind with the meeting in europe mail... Just wondering about something like that for buenos aires, or rio de janeiro... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible meeting of the minds in Europe
- Original Message - From: "Maczka Michal" <[EMAIL PROTECTED]> To: "'Maven Developers List'" <[EMAIL PROTECTED]> Sent: Tuesday, November 30, 2004 4:17 PM Subject: RE: Possible meeting of the minds in Europe > > I think sometime in January or early February would be better as it > > gives us time to prepare. I'm totally cool with Paris. If you > > folks over > > It is all fine for me. Early Febrarur is also the best date for me! If it's possible, I prefer after the 15th. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible meeting of the minds in Europe
> I think sometime in January or early February would be better as it > gives us time to prepare. I'm totally cool with Paris. If you > folks over It is all fine for me. Early Febrarur is also the best date for me! Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible meeting of the minds in Europe
On Tue, 2004-11-30 at 04:53, Vincent Massol wrote: > Hi Jason, > > I think several of us live in Paris so that could be a good choice. I would > be happy to organize this with Arnaud and Emmanuel but I'm too busy to be > able to do it properly before the 20th of December. I'm ok for anytime after > (we have to take into account Christmas holidays too). > > Anyway, let us know if you're interested in doing it in Paris around > beginning of January 2005 (which sounds the most realistic I think). > > Thanks for the initiative I think sometime in January or early February would be better as it gives us time to prepare. I'm totally cool with Paris. If you folks over in Europe agree that's a good place then it's really not much different for people flying over. But if you have the resources there to organize it then Paris is probably a good place to have it. > -Vincent > > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: lundi 29 novembre 2004 13:56 > > To: Maven Developers List > > Subject: Possible meeting of the minds in Europe > > > > Howdy, > > > > I was chatting with Brett on IRC so I thought I would bring the > > discussion here. I would like to cut a release of m2 sometime in the > > next 8 weeks but something I think would be really good would be to have > > the core folks, and anyone else who desired to come, meet up somewhere > > and discuss the v4 POM and anything else deemed important. > > > > I was thinking Europe because there are far more people there than > > anywhere else. Figure I would throw out the idea and see if we could > > organize something. If someone had an office we could use that would be > > great. There would be some organization involved but hopefully nothing > > too taxing and it would be great for everyone to meet up. There's lots > > of exciting things coming up in the near future for Maven :-) > > > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > http://maven.apache.org > > > > happiness is like a butterfly: the more you chase it, the more it will > > elude you, but if you turn your attention to other things, it will come > > and sit softly on your shoulder ... > > > > -- Thoreau > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: versioning of maven-model drops
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 2:10 PM > To: Maven Developers List > Subject: Re: versioning of maven-model drops > > [...] > This will still work - you should be able to drop in > maven-model-4.0.1 > and it still works with code that expected 4. > Converters, which care more about any version differences, > will need to > access v400 and v401. > That's why I think it is more complicated then it needs to be. The first question is what kind of converters do you imagine here? Do you imagine that we will have converters between v400 and v401?. And for example between v400 and v405? How such converters will be implemented? Will we have converters between all version pairs possible? Chained converters (v400->v401->v402-->...->v405)? I am not keen at all about having such converters as both scenarios are quite complex. I hope that once we are ready with pom v4 it will be almost never radically changed. Fundamental changes will go to v500 and m3 :) And as v405 will be backward compatible with v400 and we won't really need a converter between them - just a parser which supports both v400 and v405 in the same time. Next question is what we can really do with converters between major versions of POMs: e.g. between v3 and v4 and where and how such converter will be used? POMs v3 is fundamentaly different the POMv4 and conversion between those two versions can be partially automated but some information e.g. releated to inheriatnce, plugin configuration, preGoal, postGoals used in the project is not really easy to transform. It will be easier if we had a tool which will help to do this outside of m2 but I doubt that m2 will be able to directly support all v3 POMs and perform the required conversion is reliable way at the runtime. Do I miss something about converters or I misunderstood them completely? > >We should just not officialy release final version of POM > v4.0.0 until we > >are happy with all use cases which we want address in m2 > >(until we will reaach beta version). > > > > > This is exactly the plan. > > >I would also propose to re-think our numbering of POM > versions and use the > >following: > > > >v3 - < maven 1.0.X > >v4 - < maven 1.1.X > >v5 - < maven 2.0.X > > > > > > > I currently intend: > v3.1.0 - Maven 1.1: non breaking additions. Haven't we been planning to use new way of declaring project inheritance in 1.1 with help of groupId and artifactId versions tags (like in m)? Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPRELEASE-10) release-version only accepts valid numbers as version
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPRELEASE-10 Here is an overview of the issue: - Key: MPRELEASE-10 Summary: release-version only accepts valid numbers as version Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-release-plugin Assignee: Brett Porter Reporter: Havard Bjastad Created: Tue, 30 Nov 2004 9:06 AM Updated: Tue, 30 Nov 2004 9:06 AM Description: It seems like release-version only accepts valid numbers as version (e.g. 1.8 is accepted, but 1.8.0 is not). When trying to call I get the following exception: Caught exception evaluating: [EMAIL PROTECTED] Reason: java.lang.NumberFormatException: multiple points java.lang.NumberFormatException: multiple points at java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1067) at java.lang.Double.valueOf(Double.java:202) at java.lang.Double.(Double.java:277) at org.apache.commons.jexl.util.Coercion.coerceDouble(Coercion.java:160) at org.apache.commons.jexl.parser.ASTSubtractNode.value(ASTSubtractNode.java:109) at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.java:85) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:115) at org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSupportLocal.evaluate(JexlExpressionFactory.java:168) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:106) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:249) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233) at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266) at org.apache.maven.cli.App.doMain(App.java:486) at org.apache.maven.cli.App.main(App.java:1215) 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.wer
cvs commit: maven/xdocs/using bestpractices.xml customising.xml jar.xml migrating.xml releasing.xml war.xml developing-plugins.xml site.xml
brett 2004/11/30 05:13:13 Modified:xdocsfaq.fml navigation.xml roadmap.xml xdocs/reference command-line.xml glossary.xml project-descriptor.xml scripting.xml xdocs/start maven-for-ant-users.xml quick-start.xml ten-minute-test.xml xdocs/using developing-plugins.xml site.xml Added: xdocs/developers documentation-conventions.xml xdocs/using bestpractices.xml customising.xml jar.xml migrating.xml releasing.xml war.xml Log: addition of missing documents, mass TODO cleanup, and write the quick start guide Revision ChangesPath 1.14 +1 -0 maven/xdocs/faq.fml Index: faq.fml === RCS file: /home/cvs/maven/xdocs/faq.fml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- faq.fml 30 Nov 2004 08:34:15 - 1.13 +++ faq.fml 30 Nov 2004 13:13:13 - 1.14 @@ -242,6 +242,7 @@ ]]> + 1.53 +18 -51maven/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/maven/xdocs/navigation.xml,v retrieving revision 1.52 retrieving revision 1.53 diff -u -r1.52 -r1.53 --- navigation.xml30 Nov 2004 08:34:15 - 1.52 +++ navigation.xml30 Nov 2004 13:13:13 - 1.53 @@ -52,17 +52,16 @@ http://www.mavenblogs.com/"; /> - - + - + @@ -81,27 +80,28 @@ - - + + + - + - http://mevenide.codehaus.org/"; /> @@ -118,48 +118,15 @@ + - 1.12 +1 -1 maven/xdocs/roadmap.xml Index: roadmap.xml === RCS file: /home/cvs/maven/xdocs/roadmap.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- roadmap.xml 22 Nov 2004 11:52:57 - 1.11 +++ roadmap.xml 30 Nov 2004 13:13:13 - 1.12 @@ -22,7 +22,7 @@ Maven Roadmap Brett Porter - + 1.1 maven/xdocs/developers/documentation-conventions.xml Index: documentation-conventions.xml === Documentation Conventions Brett Porter ... 1.2 +140 -2maven/xdocs/reference/command-line.xml Index: command-line.xml === RCS file: /home/cvs/maven/xdocs/reference/command-line.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- command-line.xml 30 Nov 2004 08:34:15 - 1.1 +++ command-line.xml 30 Nov 2004 13:13:13 - 1.2 @@ -26,8 +26,146 @@ - ... - + The following command line options are available when running Maven: + + +Typically, Maven is run with a list of goals in the order they should be executed. +If no goals are specified, the default goal specified in maven.xml file. +Additionally, the following switches can be specified. Note that -P, +-g, -h, -i, -u and -v +cause Maven to exit immediately without running any goals given. + + + + OptionUsage + + + -D + +Defines a system property. This will take priority over any other property specified. +eg. maven -Dmaven.repo.remote=http://planetmirror.com/pub/maven. + + + + -E + +Output messages without adornments, making it more suitable for use in emacs. + + + + -P + +Get help with plugins. When used without any arguments, ie. maven -P, all installed +plugins are listed with a description. When a plugin name is given, the goals in that plugin are listed. +eg. maven -g jar lists the goals such as jar:jar, jar:install, and +so on. + + + + -X + +Output full debugging information while performing the build. This can be helpful in tracing what is +happening inside a plugin, or sending information to the Maven Developers about an internal bug. + +
[jira] Updated: (MAVEN-1520) maven:makeRelativePath tag is borked
The following issue has been updated:
Updater: Brett Porter (mailto:[EMAIL PROTECTED])
Date: Tue, 30 Nov 2004 8:17 AM
Changes:
Fix Version changed to 1.0.2
-
For a full history of the issue, see:
http://jira.codehaus.org/browse/MAVEN-1520?page=history
-
View the issue:
http://jira.codehaus.org/browse/MAVEN-1520
Here is an overview of the issue:
-
Key: MAVEN-1520
Summary: maven:makeRelativePath tag is borked
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
core
Fix Fors:
1.0.2
Versions:
1.0.1
Assignee:
Reporter: Hiram Chirino
Created: Mon, 29 Nov 2004 11:14 AM
Updated: Tue, 30 Nov 2004 8:17 AM
Environment: Reactor Build
Description:
Noticed the problem when the eclipse plugin started breaking a little.
I added some dubug lines to it's jelly file:
Base DIR: ${basedir}, SRC DIR: ${srcDir}, RES ${res}
Running that resulted in:
[echo] Base DIR: C:\sandbox\activemq\modules\core, SRC DIR:
C:/sandbox/activemq/src/conf, RES src/conf
I would have expectd srcDir to be "C:/sandbox/activemq/modules/core/src/conf"
not "C:/sandbox/activemq/src/conf"
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
I don't think that this is linked with snapshots. Snapshot word in version is used for underlining the work in progress but once the release is made it should be (almost) identical to the last snapshot. agreed. --general comment-- I think that we are making this whole thing more complicated then it needs to be. Don't agree. It's actually quite simple as it is. Read on... There are probably two issues related to numbering of pom versions: At the moment we have two major versions of POMs: 3 and 4. Those versions are incompatible. Then within major version we have (can have) minor versions like 4.0.0, 4.0.1 etc. The changes introduced by minor version should be no breaking - it means that we can possibly add new tags or deprecate tags but all existing tags should be supported. agree to this. Which means that in m2 which currently supports pom v4.0 we can simply put POM model into o.a.m.model.v4.* as this is not going to change anytime soon. This is just a bit ugly, and does require an overhaul when you do a major version upgrade. Keeping "latest" in o.a.m.model.* works quite well. The latest parser for each major version of POM should be able to parse all sub-versions of that version (4.0.0. 4.0.1, 4.0.2) This will still work - you should be able to drop in maven-model-4.0.1 and it still works with code that expected 4. Converters, which care more about any version differences, will need to access v400 and v401. We should just not officialy release final version of POM v4.0.0 until we are happy with all use cases which we want address in m2 (until we will reaach beta version). This is exactly the plan. I would also propose to re-think our numbering of POM versions and use the following: v3 - < maven 1.0.X v4 - < maven 1.1.X v5 - < maven 2.0.X I currently intend: v3.1.0 - Maven 1.1: non breaking additions. v4.0.0 - Maven 2.0: essentially starting from scratch, and transitive dependency enabled For m1 we indeed need to generate model to o.a.m.project.* package. The same model and parser for it can be generated to o.a.m.model.v3 and used in m2, continuum etc. exactly... Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPDIST-17) should be able to turn off creation of zip and.or tar.gz files via plugin properties
The following comment has been added to this issue: Author: Felipe Leme Created: Tue, 30 Nov 2004 5:25 AM Body: dIon, It's my time to disagree now :-( I agree with you that should keep the properties at a minimum, but this new property wouldn't be an overkill. In fact, I thing the use of such property would be much more elegant than requiring postGoals or even goals overriden. -- Felipe - View this comment: http://jira.codehaus.org/browse/MPDIST-17?page=comments#action_27285 - View the issue: http://jira.codehaus.org/browse/MPDIST-17 Here is an overview of the issue: - Key: MPDIST-17 Summary: should be able to turn off creation of zip and.or tar.gz files via plugin properties Type: Improvement Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-dist-plugin Assignee: Brett Porter Reporter: Ian P. Springer Created: Wed, 24 Nov 2004 7:49 PM Updated: Tue, 30 Nov 2004 5:25 AM Environment: n/a Description: For our project, we want to only make our dist available as a zipfile. This is because it is a Java project, and therefore we know the jar command will always be available to our users to unzip the distribution, no matter what platform they are on. So here is no need for a tar.gz dist. Unfortunately, it is currently not possible to turn off creation of the tar.gz. Can you please add some properties to control this? Something like: maven.dist.create.zip = true maven.dist.create.tar.gz = true Thanks. Ian - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1501) maven seems not to evaluate .properties of parent pom
The following comment has been added to this issue:
Author: Boris Boehlen
Created: Tue, 30 Nov 2004 5:13 AM
Body:
The workaround suggested by Wes Munsil does not work for me. I tried to set
"maven.property.inheritance=true" at the following places
* Inherited "project.properties"
* Project specific "project.properties"
* Command line
None of them solved the issue.
-
View this comment:
http://jira.codehaus.org/browse/MAVEN-1501?page=comments#action_27284
-
View the issue:
http://jira.codehaus.org/browse/MAVEN-1501
Here is an overview of the issue:
-
Key: MAVEN-1501
Summary: maven seems not to evaluate .properties of parent pom
Type: Bug
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
core
Fix Fors:
1.0.2
Versions:
1.0.1
Assignee: Brett Porter
Reporter: Thomas Minor
Created: Fri, 12 Nov 2004 10:49 AM
Updated: Tue, 30 Nov 2004 5:13 AM
Environment: [][9.2.0](10)> maven -i
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.1
# BEGIN: Which report
Which.version=Which.java:($Revision: 1.2 $) WhichJar.java:($Revision: 1.2 $)
java.version=1.4.1_06
file.encoding=ISO646-US
java.ext.dirs=/usr/j2se/jre/lib/ext
java.class.path=/home/tminor/maven-1.0.1/lib/forehead-1.0-beta-5.jar
os.name=SunOS
java.vendor=Sun Microsystems Inc.
sun.boot.class.path=/home/tminor/maven-1.0.1/lib/endorsed/xerces-2.4.0.jar:/home/tminor/maven-1.0.1/lib/endorsed/xml-apis-1.0.b2.jar:/usr/j2se/jre/lib/rt.jar:/usr/j2se/jre/lib/i18n.jar:/usr/j2se/jre/lib/sunrsasign.jar:/usr/j2se/jre/lib/jsse.jar:/usr/j2se/jre/lib/jce.jar:/usr/j2se/jre/lib/charsets.jar:/usr/j2se/jre/classes
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
# END: Which report
Installed plugins:
maven-abbot-plugin-1.1
maven-announcement-plugin-1.3
maven-ant-plugin-1.8.1
maven-antlr-plugin-1.2.1
maven-appserver-plugin-2.0
maven-artifact-plugin-1.4.1
maven-ashkelon-plugin-1.2
maven-aspectj-plugin-3.2
maven-aspectwerkz-plugin-1.2
maven-caller-plugin-1.1
maven-castor-plugin-1.2
maven-changelog-plugin-1.7.1
maven-changes-plugin-1.5.1
maven-checkstyle-plugin-2.5
maven-clean-plugin-1.3
maven-clover-plugin-1.6
maven-console-plugin-1.1
maven-cruisecontrol-plugin-1.5
maven-dashboard-plugin-1.5
maven-developer-activity-plugin-1.5.1
maven-dist-plugin-1.6.1
maven-docbook-plugin-1.2
maven-ear-plugin-1.5
maven-eclipse-plugin-1.9
maven-ejb-plugin-1.5
maven-faq-plugin-1.4
maven-file-activity-plugin-1.5.1
maven-genapp-plugin-2.2
maven-gump-plugin-1.4
maven-hibernate-plugin-1.2
maven-html2xdoc-plugin-1.3.1
maven-idea-plugin-1.5
maven-j2ee-plugin-1.5.1
maven-jalopy-plugin-1.3.1
maven-jar-plugin-1.6.1
maven-java-plugin-1.4
maven-javacc-plugin-1.1
maven-javadoc-plugin-1.7
maven-jboss-plugin-1.5
maven-jbuilder-plugin-1.5
maven-jcoverage-plugin-1.0.9
maven-jdee-plugin-1.1
maven-jdepend-plugin-1.5
maven-jdeveloper-plugin-1.4
maven-jdiff-plugin-1.4
maven-jellydoc-plugin-1.3.1
maven-jetty-plugin-1.1
maven-jira-plugin-1.1.2
maven-jnlp-plugin-1.4.1
maven-junit-doclet-plugin-1.2
maven-junit-report-plugin-1.5
maven-jxr-plugin-1.4.2
maven-latex-plugin-1.4.1
maven-latka-plugin-1.4.1
maven-license-plugin-1.2
maven-linkcheck-plugin-1.3.3
maven-multichanges-plugin-1.1
maven-multiproject-plugin-1.3.1
maven-native-plugin-1.1
maven-nsis-plugin-1.1
maven-pdf-plugin-2.2.1
maven-plugin-plugin-1.5.2
maven-pmd-plugin-1.6
maven-pom-plugin-1.4.1
maven-rar-plugin-1.0
maven-release-plugin-1.4.1
maven-repository-plugin-1.2
maven-scm-plugin-1.4.1
maven-shell-plugin-1.1
maven-simian-plugin-1.4
maven-site-plugin-1.5.2
maven-struts-plugin-1.3
maven-tasklist-plugin-2.3
maven-test-plugin-1.6.2
maven-tjdo-plugin-1.0.0
maven-uberjar-plugin-1.2
maven-vdoclet-plugin-1.2
maven-war-plugin-1.6.1
maven-webserver-plugin-2.0
maven-wizard-plugin-1.1
maven-xdoc-plugin-1.8
Home Build properties:
{maven.build.dir=/home/tminor/maven/build/${pom.groupID}/${pom.artifactId},
build.view.path=/mms, maven.home.local=/home/tminor/maven/localhome}
Description:
My pop extends an other pom.
../../project-defaults.xml
In that directory, there exists a project.properties.
This property file defines a company local, remote repository.
maven.repo.remote= http://maven./repo
Using maven 1.0, this repository is used.
When using 1.0.1, it is not used.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you
Re: Possible meeting of the minds in Europe
- Original Message - From: "Jason van Zyl" <[EMAIL PROTECTED]> To: "Maven Developers List" <[EMAIL PROTECTED]> Sent: Monday, November 29, 2004 1:55 PM Subject: Possible meeting of the minds in Europe > Howdy, > > I was chatting with Brett on IRC so I thought I would bring the > discussion here. I would like to cut a release of m2 sometime in the > next 8 weeks but something I think would be really good would be to have > the core folks, and anyone else who desired to come, meet up somewhere > and discuss the v4 POM and anything else deemed important. > > I was thinking Europe because there are far more people there than > anywhere else. Figure I would throw out the idea and see if we could > organize something. If someone had an office we could use that would be > great. There would be some organization involved but hopefully nothing > too taxing and it would be great for everyone to meet up. There's lots > of exciting things coming up in the near future for Maven :-) Excellent idea. I think Paris is the best place. There are Vincent, Arnaud and me here. If you're ok, I'll try to obtain an office. Which date ? How many people? > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://maven.apache.org > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible meeting of the minds in Europe
Hi Jason, I think several of us live in Paris so that could be a good choice. I would be happy to organize this with Arnaud and Emmanuel but I'm too busy to be able to do it properly before the 20th of December. I'm ok for anytime after (we have to take into account Christmas holidays too). Anyway, let us know if you're interested in doing it in Paris around beginning of January 2005 (which sounds the most realistic I think). Thanks for the initiative -Vincent > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: lundi 29 novembre 2004 13:56 > To: Maven Developers List > Subject: Possible meeting of the minds in Europe > > Howdy, > > I was chatting with Brett on IRC so I thought I would bring the > discussion here. I would like to cut a release of m2 sometime in the > next 8 weeks but something I think would be really good would be to have > the core folks, and anyone else who desired to come, meet up somewhere > and discuss the v4 POM and anything else deemed important. > > I was thinking Europe because there are far more people there than > anywhere else. Figure I would throw out the idea and see if we could > organize something. If someone had an office we could use that would be > great. There would be some organization involved but hopefully nothing > too taxing and it would be great for everyone to meet up. There's lots > of exciting things coming up in the near future for Maven :-) > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://maven.apache.org > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: versioning of maven-model drops
> -Original Message- > From: Trygve Laugstøl [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 9:40 AM > To: Maven Developers List > Subject: Re: versioning of maven-model drops > [...] > > So I'm thinking we can always generate releases with > versioning in the > > package name and generate the versionless package name for > our use in > > maven-core. I guess that brings up the question of how to name the > > artifacts but that's the general notions. Once we figure this out I > > would like to cut a release of maven-model and let folks try it out. > > > > Thoughts? > > +1 for releasing it. > > So the SNAPSHOT version will be without versioned packages and the > released version will be with versions? > I don't think that this is linked with snapshots. Snapshot word in version is used for underlining the work in progress but once the release is made it should be (almost) identical to the last snapshot. --general comment-- I think that we are making this whole thing more complicated then it needs to be. There are probably two issues related to numbering of pom versions: At the moment we have two major versions of POMs: 3 and 4. Those versions are incompatible. Then within major version we have (can have) minor versions like 4.0.0, 4.0.1 etc. The changes introduced by minor version should be no breaking - it means that we can possibly add new tags or deprecate tags but all existing tags should be supported. Which means that in m2 which currently supports pom v4.0 we can simply put POM model into o.a.m.model.v4.* as this is not going to change anytime soon. The latest parser for each major version of POM should be able to parse all sub-versions of that version (4.0.0. 4.0.1, 4.0.2) Note that POM is quite stable and the changes are going to be quite rare. This is not something which is going to change every week. We should just not officialy release final version of POM v4.0.0 until we are happy with all use cases which we want address in m2 (until we will reaach beta version). Everybody willing to be an early adopter of m2 when it is still in alpha stage should be prepered that things might not be stable and API and POM can change. And I think it is quite acceptable. I would also propose to re-think our numbering of POM versions and use the following: v3 - < maven 1.0.X v4 - < maven 1.1.X v5 - < maven 2.0.X For m1 we indeed need to generate model to o.a.m.project.* package. The same model and parser for it can be generated to o.a.m.model.v3 and used in m2, continuum etc. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New navigation
> I thought about it but it kind of conflicts with terminology > used to describe project inheritance and might be bit > confusing. Other problem with that is that I want to diplay more > elements then just two > > For example: > > Maven > Plugins > Maven Plugins > Maven Site Plugin > > and this is linked with classification (categorization) of > projects and that's why I used the word "taxonomy". But I am > sure there must be a better word for it :) currentLocation ? It just reminds me of a plain: $ pwd /home/joehni $ _ - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: New navigation
> -Original Message- > From: Dion Gillard [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 30, 2004 5:20 AM > To: Maven Developers List > Subject: Re: New navigation > > > Taxonomy as a name doesn't gel with the web site concepts. > > 'Parent'/'Child'? > > I thought about it but it kind of conflicts with terminology used to describe project inheritance and might be bit confusing. Other problem with that is that I want to diplay more elements then just two For example: Maven > Plugins > Maven Plugins > Maven Site Plugin and this is linked with classification (categorization) of projects and that's why I used the word "taxonomy". But I am sure there must be a better word for it :) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: versioning of maven-model drops
On man, 2004-11-29 at 16:35, Jason van Zyl wrote: > Howdy, > > There was a post on the user list about some fellow wanting to read in a > POM so I figured it would be a good opportunity to prepare some examples > for a maven-model release. > > What we are doing now is generating the most current version of the > model is generated without versioning in the package name, so it's > something like: > > org.apache.maven.model.* > > But we can optionally have versioning in the package name: > > org.apache.maven.model.v301.* > > We have used the versionless variant in the maven-core so that we don't > have the wrangle version names when we upgrade the model which I like > but if we are going to make separate utility drops should we release > them with versioning in the package name? This would be for general use > like the fellow wants to do on the user list. > > So I'm thinking we can always generate releases with versioning in the > package name and generate the versionless package name for our use in > maven-core. I guess that brings up the question of how to name the > artifacts but that's the general notions. Once we figure this out I > would like to cut a release of maven-model and let folks try it out. > > Thoughts? +1 for releasing it. So the SNAPSHOT version will be without versioned packages and the released version will be with versions? -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: maven/xdocs/start quick-start.xml
brett 2004/11/30 00:34:15 Modified:xdocsfaq.fml navigation.xml xdocs/start quick-start.xml Added: xdocs/reference command-line.xml standard-sun-jar-names.xml Log: flesh out some faq content Revision ChangesPath 1.13 +303 -369 maven/xdocs/faq.fml Index: faq.fml === RCS file: /home/cvs/maven/xdocs/faq.fml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- faq.fml 29 Nov 2004 06:58:54 - 1.12 +++ faq.fml 30 Nov 2004 08:34:15 - 1.13 @@ -19,57 +19,51 @@ - - - -Building Maven - - - How do I build Maven? - -Please see the Building Maven from Source document. - - + + +Troubleshooting Maven - - How do I build Maven from behind a firewall? - -You typically need to set your HTTP proxy host and port details so that Maven can tunnel through your -HTTP Proxy. To do this you typically need to set the maven.proxy.host and -maven.proxy.port properties. - - - - - - It has been removed from log4j.properties. It was always created in the directory Maven was run - from, and only repeated what was on the console in most cases, which was quite annoying. You can now get all - the debugging information you need and more by using the -X flag to maven. - - - Of course, if you would like to write certain information to a file and piping is not an option or you want - greater control over what is controlled, you can override the log4j configuration. Refer to the log4j - documentation for how to override this using system properties. + This can now be done using resource filtering. See this wiki entry for more information: + http://wiki.codehaus.org/maven/FilteringResources";>http://wiki.codehaus.org/maven/FilteringResources. - ---> - - -Ant + + + +Building Maven + + + How do I build Maven? + +Please see the Building Maven from Source document. + + + + + How do I build Maven from behind a firewall? + +You typically need to set your HTTP proxy host and port details so that Maven can tunnel through your +HTTP Proxy. To do this you typically need to set the maven.proxy.host and +maven.proxy.port properties. + + + 1.52 +2 -0 maven/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/maven/xdocs/navigation.xml,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- navigation.xml29 Nov 2004 06:58:54 - 1.51 +++ navigation.xml30 Nov 2004 08:34:15 - 1.52 @@ -79,6 +79,8 @@ + + Command Line Reference Brett Porter ... 1.1 maven/xdocs/reference/standard-sun-jar-names.xml Index: standard-sun-jar-names.xml === Standard Sun JAR Names Brett Porter ... 1.3 +99 -2 maven/xdocs/start/quick-start.xml Index: quick-start.xml === RCS file: /home/cvs/maven/xdocs/start/quick-start.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- quick-start.xml 29 Nov 2004 06:58:54 - 1.2 +++ quick-start.xml 30 Nov 2004 08:34:15 - 1.3 @@ -28,6 +28,105 @@ + +Ok, so you've downloaded a project that requires Maven to build, and +you've downloaded Maven and installed it. +This guide will show you how to use it on that project. + + +If you find you don't understand the meaning of a term, you should refer to the +Glossary for commonly used terminology that is +either unique to Maven or has a special meaning. + + + + +Ok, you have a project you've just downloaded, and you know it builds with Maven. +There's no documentation to speak of for the project itself, so where to start? + + + + If you were using Ant, you'd probably run ant -projecthelp, and if that didn't help, + just run "ant" and hope the default target is what you wanted. + A build.properties.sample file ma
Re: versioning of maven-model drops
Not sure what that means. It's easy now to change the name of package. ... The model was updated to the new format. I'm sure it's not quite right but not a lot of work to update. Yep, just needs to be verified. I haven't tried it in 1.1 since. All fine except for the xerces generated parser. I'd rather put the effort into making the xpp3 parser do entities and encodings. This is definitely a good idea anyway, and also my preference/ I want to avoid xerces like the plague. I understand, especially due to its speed and size, but it would be nice to have a "works like it used to" option in Maven 1.1. Let's rename that goal to "plugin to generate a SAX parser". I don't think spitting out a SAX parser in modello (not specifically xerces) would be too difficult, and people who absolutely have to have feature X from parser Y can do so. By no means am I suggesting xerces would be the default, or even distributed with later versions of Maven. WDYT? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
