[jira] Commented: (MAVEN-1407) Add mailing list address to POM
The following comment has been added to this issue: Author: Felipe Leme Created: Wed, 4 Aug 2004 12:24 AM Body: Carlos, Could you please relate this bug to: http://jira.codehaus.org/browse/MAVEN-128 -- Felipe - View this comment: http://jira.codehaus.org/browse/MAVEN-1407?page=comments#action_22707 - View the issue: http://jira.codehaus.org/browse/MAVEN-1407 Here is an overview of the issue: - Key: MAVEN-1407 Summary: Add mailing list address to POM Type: New Feature Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: model additions Assignee: Reporter: Carlos Sanchez Created: Tue, 27 Jul 2004 1:06 PM Updated: Wed, 4 Aug 2004 12:24 AM Description: - 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-118) [PATCH] Allow xdoc templates to escape XML
The following comment has been added to this issue: Author: Felipe Leme Created: Wed, 4 Aug 2004 12:22 AM Body: It doesn't work with included XML (at least I couldn't get it to :-), as shown in the test case. It work with code like this: <[CDATA[ ]]> In fact, that's what we were using in the document that originated this patch. But that contenct came from a dinamic XML, so we rather included that file than copy and paste its content again everytime it changes. But if you try: <[CDATA[ &myIncludedXml; ]]> the result would be only: &myIncludedXml; - View this comment: http://jira.codehaus.org/browse/MPXDOC-118?page=comments#action_22706 - View the issue: http://jira.codehaus.org/browse/MPXDOC-118 Here is an overview of the issue: - Key: MPXDOC-118 Summary: [PATCH] Allow xdoc templates to escape XML Type: Improvement Status: Open Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-xdoc-plugin Versions: 1.9 Assignee: Jason van Zyl Reporter: Felipe Leme Created: Tue, 3 Aug 2004 11:31 PM Updated: Wed, 4 Aug 2004 12:22 AM Description: It would be very useful if site.jsl offered a tag we could use to escape XML text. This is particularly useful when you need to include the contents of another XML file into your xdoc, as described below: 1.The way it is now, the code included inside the tags won't be escaped and hence won't be rendered (as the browser will ignore the unknown XML tags) &xmlBeingIncluded; 2.With the patch I'm including, we would use: &xmlBeingIncluded; Besides the patch, I'm providing a simple test case ilustrating the issue. in the test case provided with the patch. - 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-128) Allow more than one mailing list archive in Maven project file
The following comment has been added to this issue: Author: Felipe Leme Created: Wed, 4 Aug 2004 12:17 AM Body: Not only mail-lists.xml but also MailingList.java I will try to do these changes as this is a relative simple fix but a good exercise on how to change Maven´s API (so far I had only changed Jelly scripts). - View this comment: http://jira.codehaus.org/browse/MAVEN-128?page=comments#action_22705 - View the issue: http://jira.codehaus.org/browse/MAVEN-128 Here is an overview of the issue: - Key: MAVEN-128 Summary: Allow more than one mailing list archive in Maven project file Type: Improvement Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: model additions Fix Fors: 1.1 Assignee: Reporter: Andrew Stevens Created: Wed, 2 Oct 2002 10:57 AM Updated: Wed, 4 Aug 2004 12:17 AM Description: In the schema for the Maven project descriptor, it only allows for one archive sub-element in each mailingList element. We have some mailing lists which are archived in a few places, in particular Sourceforge's "official" archives, and Geocrawler (which has frequently been keeping up to date better recently). It would be nice if all these archive locations could be specified for the lists in the descriptor. Changing the schema to have would allow this, though I don't know where this actually gets used i.e. what other implications to templates etc. there might be. - 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-118) [PATCH] Allow xdoc templates to escape XML
The following comment has been added to this issue: Author: dion gillard Created: Wed, 4 Aug 2004 12:14 AM Body: What's wrong with ? - View this comment: http://jira.codehaus.org/browse/MPXDOC-118?page=comments#action_22704 - View the issue: http://jira.codehaus.org/browse/MPXDOC-118 Here is an overview of the issue: - Key: MPXDOC-118 Summary: [PATCH] Allow xdoc templates to escape XML Type: Improvement Status: Open Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-xdoc-plugin Versions: 1.9 Assignee: Jason van Zyl Reporter: Felipe Leme Created: Tue, 3 Aug 2004 11:31 PM Updated: Wed, 4 Aug 2004 12:14 AM Description: It would be very useful if site.jsl offered a tag we could use to escape XML text. This is particularly useful when you need to include the contents of another XML file into your xdoc, as described below: 1.The way it is now, the code included inside the tags won't be escaped and hence won't be rendered (as the browser will ignore the unknown XML tags) &xmlBeingIncluded; 2.With the patch I'm including, we would use: &xmlBeingIncluded; Besides the patch, I'm providing a simple test case ilustrating the issue. in the test case provided with the patch. - 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-118) [PATCH] Allow xdoc templates to escape XML
The following issue has been updated: Updater: Felipe Leme (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 11:42 PM Comment: Screenshot of the test case Changes: Attachment changed to Screenshot-MPXDOC-118.png - For a full history of the issue, see: http://jira.codehaus.org/browse/MPXDOC-118?page=history - View the issue: http://jira.codehaus.org/browse/MPXDOC-118 Here is an overview of the issue: - Key: MPXDOC-118 Summary: [PATCH] Allow xdoc templates to escape XML Type: Improvement Status: Open Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-xdoc-plugin Versions: 1.9 Assignee: Jason van Zyl Reporter: Felipe Leme Created: Tue, 3 Aug 2004 11:31 PM Updated: Tue, 3 Aug 2004 11:42 PM Description: It would be very useful if site.jsl offered a tag we could use to escape XML text. This is particularly useful when you need to include the contents of another XML file into your xdoc, as described below: 1.The way it is now, the code included inside the tags won't be escaped and hence won't be rendered (as the browser will ignore the unknown XML tags) &xmlBeingIncluded; 2.With the patch I'm including, we would use: &xmlBeingIncluded; Besides the patch, I'm providing a simple test case ilustrating the issue. in the test case provided with the patch. - 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-118) [PATCH] Allow xdoc templates to escape XML
The following issue has been updated: Updater: Felipe Leme (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 11:40 PM Comment: Test case - just run 'maven xdoc' on it and see the results... Changes: Attachment changed to testcase-mpxdoc-118.zip - For a full history of the issue, see: http://jira.codehaus.org/browse/MPXDOC-118?page=history - View the issue: http://jira.codehaus.org/browse/MPXDOC-118 Here is an overview of the issue: - Key: MPXDOC-118 Summary: [PATCH] Allow xdoc templates to escape XML Type: Improvement Status: Open Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-xdoc-plugin Versions: 1.9 Assignee: Jason van Zyl Reporter: Felipe Leme Created: Tue, 3 Aug 2004 11:31 PM Updated: Tue, 3 Aug 2004 11:40 PM Description: It would be very useful if site.jsl offered a tag we could use to escape XML text. This is particularly useful when you need to include the contents of another XML file into your xdoc, as described below: 1.The way it is now, the code included inside the tags won't be escaped and hence won't be rendered (as the browser will ignore the unknown XML tags) &xmlBeingIncluded; 2.With the patch I'm including, we would use: &xmlBeingIncluded; Besides the patch, I'm providing a simple test case ilustrating the issue. in the test case provided with the patch. - 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-118) [PATCH] Allow xdoc templates to escape XML
The following issue has been updated: Updater: Felipe Leme (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 11:39 PM Comment: Proposed patch. Changes: Attachment changed to mpxdoc-118.patch - For a full history of the issue, see: http://jira.codehaus.org/browse/MPXDOC-118?page=history - View the issue: http://jira.codehaus.org/browse/MPXDOC-118 Here is an overview of the issue: - Key: MPXDOC-118 Summary: [PATCH] Allow xdoc templates to escape XML Type: Improvement Status: Open Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-xdoc-plugin Versions: 1.9 Assignee: Jason van Zyl Reporter: Felipe Leme Created: Tue, 3 Aug 2004 11:31 PM Updated: Tue, 3 Aug 2004 11:39 PM Description: It would be very useful if site.jsl offered a tag we could use to escape XML text. This is particularly useful when you need to include the contents of another XML file into your xdoc, as described below: 1.The way it is now, the code included inside the tags won't be escaped and hence won't be rendered (as the browser will ignore the unknown XML tags) &xmlBeingIncluded; 2.With the patch I'm including, we would use: &xmlBeingIncluded; Besides the patch, I'm providing a simple test case ilustrating the issue. in the test case provided with the patch. - 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-118) [PATCH] Allow xdoc templates to escape XML
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPXDOC-118 Here is an overview of the issue: - Key: MPXDOC-118 Summary: [PATCH] Allow xdoc templates to escape XML Type: Improvement Status: Open Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-xdoc-plugin Versions: 1.9 Assignee: Jason van Zyl Reporter: Felipe Leme Created: Tue, 3 Aug 2004 11:31 PM Updated: Tue, 3 Aug 2004 11:31 PM Description: It would be very useful if site.jsl offered a tag we could use to escape XML text. This is particularly useful when you need to include the contents of another XML file into your xdoc, as described below: 1.The way it is now, the code included inside the tags won't be escaped and hence won't be rendered (as the browser will ignore the unknown XML tags) &xmlBeingIncluded; 2.With the patch I'm including, we would use: &xmlBeingIncluded; Besides the patch, I'm providing a simple test case ilustrating the issue. in the test case provided with the patch. - 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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
The following comment has been added to this issue: Author: dion gillard Created: Tue, 3 Aug 2004 9:33 PM Body: Does maven scm:cvs-create-patch create a correct patch file, or does that goal need changing to handle whitespace? - View this comment: http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_22700 - View the issue: http://jira.codehaus.org/browse/MAVEN-1410 Here is an overview of the issue: - Key: MAVEN-1410 Summary: pom.artifactId is missing from XML schema and pom.id should be removed Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: model Versions: 1.0 Assignee: Reporter: Dennis Lundberg Created: Fri, 30 Jul 2004 4:06 PM Updated: Tue, 3 Aug 2004 9:33 PM Description: After some discussion on the dev-list "pom.id versus pom.artifactId - which is correct?" there seems to be some inconsistencies in the 1.0 release. The discussion resulted in the following conclusions: 1. The element project.id should be removed from the XML schema 2. The element project.artifactId should be added to the XML schema 3. Documentation needs to be updated to reflect the above issues 1 and 2 should probably be done by one of the core developers, including decisions regarding version numbers for the XML schema. I can make a patch for it if you think that's ok. I can make patches for the xdocs to fix 3. On which branch should I create the patches? - 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: [VOTE] Options for the Jakarta Taglibs Maven repository
Brett Porter wrote: The Maven developers have been discussing the future repository format so I can speak with reasonable authority on this. [X] +1 Put everything in one directory (such as jakarta-taglibs) Advantage: less groups on ibiblio Disadvantage: the group is going to be huge (around 30-80 files on each artifact sub-dir) What do you mean "each artifact sub-dir"? I imagine this is less work for you, and is best compatible with the future direction. This is my vote. So you'd start out with: taglibs/jars/taglibs-standard-1.0.1.jar (I'd stick with the existing taglibs group for now). When you convert to Maven, this means your groupID is "taglibs" and your artifactId is "taglibs-XXX" for each project. I think we'll have jakarta-commons move that way in the long run, eventually with a structure like org/apache/jakarta/commons/collections/1.0.1/commons-collections-1.0.1.jar. wouldn't it be: org/apache/jakarta/commons/collections/1.0.1/collections-1.0.1.jar as "collections" is the artifact id and "org/apache/jakarta/commons" is the group heirarchy? In which case it would be the following for taglibs after we've made such a transition: org/apache/jakarta/taglibs/1.0.1/standard-1.0.1.jar and until then, I think your right that it would be taglibs/jars/taglibs-standard-1.0.1.jar So if we were to define a list of goals to make the transition to a "new" repository structure, what would they look like? 1.) migrate commons from individual project directories to a single project directory (IE) commons-collections/jars/commons-collections-1.0.1.jar commons-beanutils/jars/commons-beanutils-1.0.1.jar -to- commons/jars/commons-collections-1.0.1.jar commons/jars/commons-beanutils-1.0.1.jar 2.) make sure all projects maintain this strategy. (IE) taglibs/jars/taglibs-standard-1.0.1.jar taglibs/jars/taglibs-jndi-1.0.1.jar 3.) convert everything one day in the future to: org/apache/jakarta/commons/collections/1.0.1/collections-1.0.1.jar org/apache/jakarta/commons/beanutils/1.0.1/beanutils-1.0.1.jar org/apache/jakarta/taglibs/standard/1.0.1/standard-1.0.1.jar org/apache/jakarta/taglibs/jndi/1.0.1/jndi-1.0.1.jar Is this the plan? -- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Carlos Sanchez wrote: Hi, I just think that jstl shouldn't be mixed with concrete implementations. That whats tough about Sun releasing jars as a standard. Where should the api's be stored! Ultimately, I believe there are distribution "clauses" in the lisences for these things that allow us to distribute them in Apache software, this should also probibly apply to the repository as well. The point in keeping this separate from the taglibs is that they can be maintained as to not have multiple copies in the repository. For instance, if tomcat releases jasper with jstl included and taglibs releases standard with the jstl ja included too, then there are two copies of the jar present in the repository. Where, if they both list them separately as a dependency, then we can maintain just a single copy of the jar in the repository as a separate project, both can reference it as a dependency, thus I think its important that it be separate, just like the servletapi. About the other issues with group names maybe we should consider the repository layout. Currently anyone can request an upload to any group and I think this won't scale well and can lead to conflict problems. Having strict naming conventions will avoid problems like those happening now with jakarta-taglibs. A solution could be adding the domain or package name in some way, e.g. apache.jakarta.taglibs apache-jakarta-taglibs apache/jakarta/taglibs Like Brett said, we just don't have the transition to those naming conventions stablized yet (sigh) is a very painfull transition that is being held off because it will impact so many projects when it happens. So his argument that we should just use "taglibs" for now is valid in that it may all change in the near future when we attempt this transition. I'll retract my statement that they should be separate project directories (taglibs-standard, taglibs-jndi, etc) because if we are consolidating commons into one directory structure as a goal then other projects should follow this theme. -Mark Anything after the domain name would be responsability of the domain owner. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Felipe Leme [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 1:19 PM To: Maven Developers List Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository Oops, forgot my votes: > 1.Multiple directories x one directory: > [X ] +1 Create one directory for group (ex: taglibs-standard, > taglibs-request). > Advantages: easier to locate artifacts; consistent with the way > Jakarta Commons is organized > 3.Where to put jstl.jar > [X] +1 On existing group jstl > Advantage: no replication of existing directory; better separation > between specification (JSTL) and implementation (Jakarta Standard > Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - 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] -- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Brett Porter wrote: I thought I should discuss a little further since Mark disagrees on some points here. +1 The decision on which structure to use should be more dependent on the "type" of group structure you have. If you expect the various "subgroups" of your group to be releasing on separate schedules and/or have new sub-groups created, then I would recommend you place the artifacts into their own project directories. This way the various groups can maintain separate directory structures with separate contents, which will be easier to manage. I couldn't parse this statement at all (no coffee :), so sorry if I'm on the wrong track with what you said. I don't see what the release schedule has to do with the directory structure. Releasing is pushing to a directory and you don't need to do anything there after that. Perhaps it would be best if you could reply to anything you don't agree with on my other email just sent as a starting point for a discussion. I think I'm the one who didn't have enough coffee when I wrote this... ;-) I'll respond in kind to your other thread. -- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Options for the Jakarta Taglibs Maven repository
Rather than going over it all, it might be helpful to read this: http://docs.codehaus.org/display/MAVEN/Repository+-+Layout Cheers, Brett Quoting Carlos Sanchez <[EMAIL PROTECTED]>: > Hi, > > I just think that jstl shouldn't be mixed with concrete implementations. > > About the other issues with group names maybe we should consider the > repository layout. Currently anyone can request an upload to any group and I > think this won't scale well and can lead to conflict problems. Having strict > naming conventions will avoid problems like those happening now with > jakarta-taglibs. A solution could be adding the domain or package name in > some way, e.g. > apache.jakarta.taglibs > apache-jakarta-taglibs > apache/jakarta/taglibs > > Anything after the domain name would be responsability of the domain owner. > > Regards > > Carlos Sanchez > A Coruña, Spain > > Oness Project > http://oness.sourceforge.net > > > > -Original Message- > > From: Felipe Leme [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 03, 2004 1:19 PM > > To: Maven Developers List > > Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository > > > > Oops, forgot my votes: > > > > > 1.Multiple directories x one directory: > > > [X ] +1 Create one directory for group (ex: > > taglibs-standard, > taglibs-request). > > > Advantages: easier to locate artifacts; consistent with > > the way > Jakarta Commons is organized > > > > > 3.Where to put jstl.jar > > > [X] +1 On existing group jstl > > > Advantage: no replication of existing directory; > > better separation > > > between specification (JSTL) and implementation (Jakarta > > Standard > Taglibs) > > > > For this one, I changed my mind after Carlos' messages... > > > > > > -- Felipe > > > > > > - > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1208) project.xml in docs doesn't validate
The following comment has been added to this issue: Author: Dennis Lundberg Created: Tue, 3 Aug 2004 4:39 PM Body: MAVEN-1386 solves the documentation issues. The POM in the current, although not yet released, integrate.xml does validate. We should await MAVEN-1410 before closing this, because that issue involves changes to integrate.xml. - View this comment: http://jira.codehaus.org/browse/MAVEN-1208?page=comments#action_22697 - View the issue: http://jira.codehaus.org/browse/MAVEN-1208 Here is an overview of the issue: - Key: MAVEN-1208 Summary: project.xml in docs doesn't validate Type: Bug Status: Open Priority: Minor Original Estimate: 5 minutes Time Spent: Unknown Remaining: 5 minutes Project: maven Components: documentation Fix Fors: 1.0.1 Versions: 1.0-rc2 Assignee: Brett Porter Reporter: Philip Crotwell Created: Wed, 24 Mar 2004 12:38 PM Updated: Tue, 3 Aug 2004 4:39 PM Description: The project.xml at http://maven.apache.org/start/integrate.html has errors with maven pom:validate The errors are: line 4: id should be before name, not after line 17: shortDescription should be below gump and description line 181: integrationUnitTest shouldn't be there at all. I suppose these could be looked at either as documentation errors, or errors in the xschema, not sure which is more correct. - 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: (MAVEN-1413) StackOverflowError in maven:reactor when invoking Maven from Ant
The following issue has been updated: Updater: Jeff French (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 3:54 PM Comment: My bias for UNIX was showing with that TAR file. Here is a ZIP file as well. Changes: Attachment changed to maven-1413.zip - For a full history of the issue, see: http://jira.codehaus.org/browse/MAVEN-1413?page=history - View the issue: http://jira.codehaus.org/browse/MAVEN-1413 Here is an overview of the issue: - Key: MAVEN-1413 Summary: StackOverflowError in maven:reactor when invoking Maven from Ant Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0 Assignee: Reporter: Jeff French Created: Tue, 3 Aug 2004 3:46 PM Updated: Tue, 3 Aug 2004 3:54 PM Environment: Mandrake 9.0, JDK 1.4.2, Maven 1.0 final, Ant 1.5.3-1, AnthillOS 1.6.3.67. Of these, only the Maven version has changed in the past several months. Description: I use Anthill for my build tool. Since it does not run Maven directly, I use an Ant build.xml wrapper around Maven. This worked fine through RC4, but started giving a StackOverflowError in maven:reactor after upgrading to 1.0 Final. I've traced it down to the following. In my Ant wrapper: If mdb.version has a value, this works. If mdb.version is not defined, I get the StackOverflowError for 1.0 Final, but not RC4. - 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: (MAVEN-1413) StackOverflowError in maven:reactor when invoking Maven from Ant
The following issue has been updated: Updater: Jeff French (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 3:49 PM Comment: I have attached a small project that demonstrates the problem. When you untar, you'll get an 'ant' and 'maven' directory. Type this at the command line: ant -f ant/build.xml to see the error under 1.0 Final. Uncomment the line indicated in ant/build.xml to make it work, or run using RC4 Changes: Attachment changed to maven-1413.tar - For a full history of the issue, see: http://jira.codehaus.org/browse/MAVEN-1413?page=history - View the issue: http://jira.codehaus.org/browse/MAVEN-1413 Here is an overview of the issue: - Key: MAVEN-1413 Summary: StackOverflowError in maven:reactor when invoking Maven from Ant Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0 Assignee: Reporter: Jeff French Created: Tue, 3 Aug 2004 3:46 PM Updated: Tue, 3 Aug 2004 3:49 PM Environment: Mandrake 9.0, JDK 1.4.2, Maven 1.0 final, Ant 1.5.3-1, AnthillOS 1.6.3.67. Of these, only the Maven version has changed in the past several months. Description: I use Anthill for my build tool. Since it does not run Maven directly, I use an Ant build.xml wrapper around Maven. This worked fine through RC4, but started giving a StackOverflowError in maven:reactor after upgrading to 1.0 Final. I've traced it down to the following. In my Ant wrapper: If mdb.version has a value, this works. If mdb.version is not defined, I get the StackOverflowError for 1.0 Final, but not RC4. - 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: (MAVEN-1413) StackOverflowError in maven:reactor when invoking Maven from Ant
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MAVEN-1413 Here is an overview of the issue: - Key: MAVEN-1413 Summary: StackOverflowError in maven:reactor when invoking Maven from Ant Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0 Assignee: Reporter: Jeff French Created: Tue, 3 Aug 2004 3:46 PM Updated: Tue, 3 Aug 2004 3:46 PM Environment: Mandrake 9.0, JDK 1.4.2, Maven 1.0 final, Ant 1.5.3-1, AnthillOS 1.6.3.67. Of these, only the Maven version has changed in the past several months. Description: I use Anthill for my build tool. Since it does not run Maven directly, I use an Ant build.xml wrapper around Maven. This worked fine through RC4, but started giving a StackOverflowError in maven:reactor after upgrading to 1.0 Final. I've traced it down to the following. In my Ant wrapper: If mdb.version has a value, this works. If mdb.version is not defined, I get the StackOverflowError for 1.0 Final, but not RC4. - 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: (MAVEN-1410) pom.artifactId is missing from XML schema and pom.id should be removed
The following issue has been updated: Updater: Dennis Lundberg (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 2:47 PM Comment: Added a patch for the XSD for MAVEN-1_0-BRANCH. Changes: Attachment changed to maven-project.xsd-1_0-BRANCH.patch - For a full history of the issue, see: http://jira.codehaus.org/browse/MAVEN-1410?page=history - View the issue: http://jira.codehaus.org/browse/MAVEN-1410 Here is an overview of the issue: - Key: MAVEN-1410 Summary: pom.artifactId is missing from XML schema and pom.id should be removed Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: model Versions: 1.0 Assignee: Reporter: Dennis Lundberg Created: Fri, 30 Jul 2004 4:06 PM Updated: Tue, 3 Aug 2004 2:47 PM Description: After some discussion on the dev-list "pom.id versus pom.artifactId - which is correct?" there seems to be some inconsistencies in the 1.0 release. The discussion resulted in the following conclusions: 1. The element project.id should be removed from the XML schema 2. The element project.artifactId should be added to the XML schema 3. Documentation needs to be updated to reflect the above issues 1 and 2 should probably be done by one of the core developers, including decisions regarding version numbers for the XML schema. I can make a patch for it if you think that's ok. I can make patches for the xdocs to fix 3. On which branch should I create the patches? - 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: (MAVEN-1410) pom.artifactId is missing from XML schema and pom.id should be removed
The following issue has been updated: Updater: Dennis Lundberg (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 2:32 PM Comment: Oops! An IDE that eats whitespace at the end of lines and a diff-tool with the "Ignore differences in whitespace"-checkbox checked is a dangerous combination :-) A new version of the documentation patches is attached. Changes: Attachment changed to xdocs-artifactId-version2.patch - For a full history of the issue, see: http://jira.codehaus.org/browse/MAVEN-1410?page=history - View the issue: http://jira.codehaus.org/browse/MAVEN-1410 Here is an overview of the issue: - Key: MAVEN-1410 Summary: pom.artifactId is missing from XML schema and pom.id should be removed Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: model Versions: 1.0 Assignee: Reporter: Dennis Lundberg Created: Fri, 30 Jul 2004 4:06 PM Updated: Tue, 3 Aug 2004 2:32 PM Description: After some discussion on the dev-list "pom.id versus pom.artifactId - which is correct?" there seems to be some inconsistencies in the 1.0 release. The discussion resulted in the following conclusions: 1. The element project.id should be removed from the XML schema 2. The element project.artifactId should be added to the XML schema 3. Documentation needs to be updated to reflect the above issues 1 and 2 should probably be done by one of the core developers, including decisions regarding version numbers for the XML schema. I can make a patch for it if you think that's ok. I can make patches for the xdocs to fix 3. On which branch should I create the patches? - 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-181) D-Haven Event 1.0.3
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MAVENUPLOAD-181 Here is an overview of the issue: - Key: MAVENUPLOAD-181 Summary: D-Haven Event 1.0.3 Type: Improvement Status: Open Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-upload-requests Assignee: Jason van Zyl Reporter: Berin Loritsch Created: Tue, 3 Aug 2004 1:59 PM Updated: Tue, 3 Aug 2004 1:59 PM Description: http://dist.d-haven.org/d-haven-event-1.0.3-bundle.jar D-Haven Event 1.0.3 addresses an issue brought up by Niklas Therning where the pipeline operated in a LIFO fashion. This was not the intent of the library, and the tests and fixes have been implemented. All pipelines operate in FIFO fashion as expected. - 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: (MPANNOUNCEMENT-14) [PATCH] Check if there is a SCM tag set for the project
The following issue has been updated: Updater: Felipe Leme (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 1:52 PM Comment: Patch that checks if the project's current version is on the POM's versions element. Changes: Attachment changed to mpannouncement-14.patch - For a full history of the issue, see: http://jira.codehaus.org/browse/MPANNOUNCEMENT-14?page=history - View the issue: http://jira.codehaus.org/browse/MPANNOUNCEMENT-14 Here is an overview of the issue: - Key: MPANNOUNCEMENT-14 Summary: [PATCH] Check if there is a SCM tag set for the project Type: Improvement Status: Unassigned Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-announcement-plugin Versions: 1.3 Assignee: Reporter: Felipe Leme Created: Tue, 3 Aug 2004 1:48 PM Updated: Tue, 3 Aug 2004 1:52 PM Description: As I mentioned earlier in the dev-list, if the POM defines a element, than the current version should have an equivalent there, otherwise check-version should fail. If that happens, announcement:check-version will show this message: Current release (XXX) does not have an entry at the POM's versions element. -- Felipe - 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: (MPANNOUNCEMENT-14) [PATCH] Check if there is a SCM tag set for the project
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MPANNOUNCEMENT-14 Here is an overview of the issue: - Key: MPANNOUNCEMENT-14 Summary: [PATCH] Check if there is a SCM tag set for the project Type: Improvement Status: Unassigned Priority: Trivial Original Estimate: 10 minutes Time Spent: Unknown Remaining: 10 minutes Project: maven-announcement-plugin Versions: 1.3 Assignee: Reporter: Felipe Leme Created: Tue, 3 Aug 2004 1:48 PM Updated: Tue, 3 Aug 2004 1:48 PM Description: As I mentioned earlier in the dev-list, if the POM defines a element, than the current version should have an equivalent there, otherwise check-version should fail. If that happens, announcement:check-version will show this message: Current release (XXX) does not have an entry at the POM's versions element. -- Felipe - 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: [VOTE] Options for the Jakarta Taglibs Maven repository@cpqd.com.br
On Tue, 3 Aug 2004 16:29:06 +0200, "Nicolas De Loof" <[EMAIL PROTECTED]> wrote: > Just a suggestion, that may be a bad idea... I don't think it's a bad idea, but... > What about setting groupid to "taglibs/standard" ? > That may allow using a more hierarchical repository (www.ibiblio.org/maven has so much directories...) According to Brett's previous message, looks like that's the plan for the future. So we better not apply that structure now... Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Options for the Jakarta Taglibs Maven repository
Hi, I just think that jstl shouldn't be mixed with concrete implementations. About the other issues with group names maybe we should consider the repository layout. Currently anyone can request an upload to any group and I think this won't scale well and can lead to conflict problems. Having strict naming conventions will avoid problems like those happening now with jakarta-taglibs. A solution could be adding the domain or package name in some way, e.g. apache.jakarta.taglibs apache-jakarta-taglibs apache/jakarta/taglibs Anything after the domain name would be responsability of the domain owner. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net > -Original Message- > From: Felipe Leme [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 03, 2004 1:19 PM > To: Maven Developers List > Subject: Re: [VOTE] Options for the Jakarta Taglibs Maven repository > > Oops, forgot my votes: > > > 1.Multiple directories x one directory: > > [X ] +1 Create one directory for group (ex: > taglibs-standard, > taglibs-request). > > Advantages: easier to locate artifacts; consistent with > the way > Jakarta Commons is organized > > > 3.Where to put jstl.jar > > [X] +1 On existing group jstl > > Advantage: no replication of existing directory; > better separation > > between specification (JSTL) and implementation (Jakarta > Standard > Taglibs) > > For this one, I changed my mind after Carlos' messages... > > > -- Felipe > > > - > 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]
[jira] Created: (MODELLO-9) Allow to define if a field is a tag or an attribute
Message: A new issue has been created in JIRA. - View the issue: http://jira.codehaus.org/browse/MODELLO-9 Here is an overview of the issue: - Key: MODELLO-9 Summary: Allow to define if a field is a tag or an attribute Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: modello Assignee: Jason van Zyl Reporter: Emmanuel Venisse Created: Tue, 3 Aug 2004 10:36 AM Updated: Tue, 3 Aug 2004 10:36 AM Description: - 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: (MPANNOUNCEMENT-9) Add a goal to send the announcement by mail to a list of email addresses
The following comment has been added to this issue: Author: Felipe Leme Created: Tue, 3 Aug 2004 10:33 AM Body: > cvs diff -uN > should do the trick Yes, it would work only if I had 'cvs added' the files first, but unfortunately that didn't work neither (see previous post). :-( - View this comment: http://jira.codehaus.org/browse/MPANNOUNCEMENT-9?page=comments#action_22687 - View the issue: http://jira.codehaus.org/browse/MPANNOUNCEMENT-9 Here is an overview of the issue: - Key: MPANNOUNCEMENT-9 Summary: Add a goal to send the announcement by mail to a list of email addresses Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-announcement-plugin Versions: 1.2 Assignee: Vincent Massol Reporter: Vincent Massol Created: Thu, 8 Jul 2004 4:16 AM Updated: Tue, 3 Aug 2004 10:33 AM Description: - 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: [VOTE] Options for the Jakarta Taglibs Maven repository
Just a suggestion, that may be a bad idea...
What about setting groupid to "taglibs/standard" ?
That may allow using a more hierarchical repository (www.ibiblio.org/maven has so much
directories...)
repository_root
- taglibs
- standard
-
- artifact-version.jar
- string
...
...
I've tried it with maven 1.0RC4 and it works !
Nico.
> I thought I should discuss a little further since Mark disagrees on some points here.
>
> > +1 The decision on which structure to use should be more dependent on
> > the "type" of group structure you have. If you expect the various
> > "subgroups" of your group to be releasing on separate schedules and/or
> > have new sub-groups created, then I would recommend you place the
> > artifacts into their own project directories. This way the various
> > groups can maintain separate directory structures with separate
> > contents, which will be easier to manage.
>
> I couldn't parse this statement at all (no coffee :), so sorry if I'm on the wrong
> track with
> what you said. I don't see what the release schedule has to do with the directory
> structure.
> Releasing is pushing to a directory and you don't need to do anything there after
> that.
>
> Perhaps it would be best if you could reply to anything you don't agree with on my
> other
> email just sent as a starting point for a discussion.
>
> > > 2.(In case one directory wins previous poll)
> > > [ ] +1 Use new directory 'jakarta-taglibs
> > >Advantage: better identify which taglibs that group refers too
> > >Disadvantage: replication of existing directory ('taglibs')
> >
> > +1 just because an old directory exists, doesn't mean that you as the
> > individual managing taglibs maven release can't choose a new one, your
> > the "canonical" source for these files. 'taglibs' is very generic.
>
> I agree on this point, I just know that we have a plan to resolve this issue, so
> would prefer
> that it stay the same now. Having said that, if you desperately want
> jakarta-taglibs, that's
> a non-issue for me really.
>
> > > [ ] +1 Use existing directory 'taglibs'
> > >Advantage: no replication of existing directory
> > >Disadvantage: name is too generic
> >
> > -1 I agree, we see this problem arise in other areas of the repository,
> > if it can be cleaned out, (or deprecated as the other thread suggests,
> > that would be good)
>
> As above, since no deprecation is available, I think it is better to keep this for
> now.
>
> Thanks!
> - Brett
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
Our name has changed. Please update your address book to the following format:
"[EMAIL PROTECTED]".
This message contains information that may be privileged or confidential and is the
property of the Capgemini Group. It is intended only for the person to whom it is
addressed. If you are not the intended recipient, you are not authorized to read,
print, retain, copy, disseminate, distribute, or use this message or any part
thereof. If you receive this message in error, please notify the sender immediately
and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPANNOUNCEMENT-9) Add a goal to send the announcement by mail to a list of email addresses
The following comment has been added to this issue: Author: Brett Porter Created: Tue, 3 Aug 2004 10:27 AM Body: just on new files and CVS: cvs diff -uN should do the trick - View this comment: http://jira.codehaus.org/browse/MPANNOUNCEMENT-9?page=comments#action_22686 - View the issue: http://jira.codehaus.org/browse/MPANNOUNCEMENT-9 Here is an overview of the issue: - Key: MPANNOUNCEMENT-9 Summary: Add a goal to send the announcement by mail to a list of email addresses Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-announcement-plugin Versions: 1.2 Assignee: Vincent Massol Reporter: Vincent Massol Created: Thu, 8 Jul 2004 4:16 AM Updated: Tue, 3 Aug 2004 10:27 AM Description: - 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-1410) pom.artifactId is missing from XML schema and pom.id should be removed
The following comment has been added to this issue: Author: Brett Porter Created: Tue, 3 Aug 2004 10:24 AM Body: Thanks - looks good. Could you possibly redo the HEAD patch without the whitespace changes? diff -wb I think. The XSD change should be applied to MAVEN-1_0-BRANCH as well on the maven-project.xsd file. - View this comment: http://jira.codehaus.org/browse/MAVEN-1410?page=comments#action_22685 - View the issue: http://jira.codehaus.org/browse/MAVEN-1410 Here is an overview of the issue: - Key: MAVEN-1410 Summary: pom.artifactId is missing from XML schema and pom.id should be removed Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Components: model Versions: 1.0 Assignee: Reporter: Dennis Lundberg Created: Fri, 30 Jul 2004 4:06 PM Updated: Tue, 3 Aug 2004 10:24 AM Description: After some discussion on the dev-list "pom.id versus pom.artifactId - which is correct?" there seems to be some inconsistencies in the 1.0 release. The discussion resulted in the following conclusions: 1. The element project.id should be removed from the XML schema 2. The element project.artifactId should be added to the XML schema 3. Documentation needs to be updated to reflect the above issues 1 and 2 should probably be done by one of the core developers, including decisions regarding version numbers for the XML schema. I can make a patch for it if you think that's ok. I can make patches for the xdocs to fix 3. On which branch should I create the patches? - 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: [VOTE] Options for the Jakarta Taglibs Maven repository
I thought I should discuss a little further since Mark disagrees on some points here.
> +1 The decision on which structure to use should be more dependent on
> the "type" of group structure you have. If you expect the various
> "subgroups" of your group to be releasing on separate schedules and/or
> have new sub-groups created, then I would recommend you place the
> artifacts into their own project directories. This way the various
> groups can maintain separate directory structures with separate
> contents, which will be easier to manage.
I couldn't parse this statement at all (no coffee :), so sorry if I'm on the wrong
track with
what you said. I don't see what the release schedule has to do with the directory
structure.
Releasing is pushing to a directory and you don't need to do anything there after that.
Perhaps it would be best if you could reply to anything you don't agree with on my
other
email just sent as a starting point for a discussion.
> > 2.(In case one directory wins previous poll)
> > [ ] +1 Use new directory 'jakarta-taglibs
> >Advantage: better identify which taglibs that group refers too
> >Disadvantage: replication of existing directory ('taglibs')
>
> +1 just because an old directory exists, doesn't mean that you as the
> individual managing taglibs maven release can't choose a new one, your
> the "canonical" source for these files. 'taglibs' is very generic.
I agree on this point, I just know that we have a plan to resolve this issue, so would
prefer
that it stay the same now. Having said that, if you desperately want jakarta-taglibs,
that's
a non-issue for me really.
> > [ ] +1 Use existing directory 'taglibs'
> >Advantage: no replication of existing directory
> >Disadvantage: name is too generic
>
> -1 I agree, we see this problem arise in other areas of the repository,
> if it can be cleaned out, (or deprecated as the other thread suggests,
> that would be good)
As above, since no deprecation is available, I think it is better to keep this for now.
Thanks!
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
The Maven developers have been discussing the future repository format so I can speak
with reasonable authority on this.
> [X] +1 Put everything in one directory (such as jakarta-taglibs)
>Advantage: less groups on ibiblio
>Disadvantage: the group is going to be huge (around 30-80 files on
> each artifact sub-dir)
What do you mean "each artifact sub-dir"?
I imagine this is less work for you, and is best compatible with the future direction.
This is my vote. So you'd start out with:
taglibs/jars/taglibs-standard-1.0.1.jar
(I'd stick with the existing taglibs group for now).
When you convert to Maven, this means your groupID is "taglibs" and your artifactId
is "taglibs-XXX" for each project.
I think we'll have jakarta-commons move that way in the long run, eventually with a
structure like
org/apache/jakarta/commons/collections/1.0.1/commons-collections-1.0.1.jar.
> [ ] +1 Create one directory for group (ex: taglibs-standard,
> taglibs-request).
>Advantages: easier to locate artifacts; consistent with the way
> Jakarta Commons is organized
> [ ] +0 Doesn't matter for me
This will further nuke ibiblio's root directory. -1.
> 2.(In case one directory wins previous poll)
> [ ] +1 Use new directory 'jakarta-taglibs
>Advantage: better identify which taglibs that group refers too
>Disadvantage: replication of existing directory ('taglibs')
> [X] +1 Use existing directory 'taglibs'
>Advantage: no replication of existing directory
>Disadvantage: name is too generic
> [ ] +0 Doesn't matter for me
just echoing above. Will fix it later, but for now I'd say we can keep it as is
without
affecting users. It will be reserved for jakarta-taglibs, not for any taglibs project.
> 3.Where to put jstl.jar
Is this something you've built, or is it from Sun? We can't redistribute it if it is
from Sun due
to the license. Assuming it is something built by taglibs, I think taglibs-jstl.jar is
appropriate
and can be put in the taglibs directory too.
> [ ] +1 Wherever standard.jar is
> Advantage: jstl.jar is created by Jakarta Standard Taglibs
> Disadvantage: it's a JCP API of its own; replication of existing
> directory ('jstl')
> [ ] +1 On existing group jstl
> Advantage: no replication of existing directory; better separation
> between specification (JSTL) and implementation (Jakarta Standard
> Taglibs)
> Disadvantage: jar is created by another project (there is no JSTL
> project on Jakarta/ASF); inconsistent with another groups (like
> servletapi)
> [ ] +1 On new group jstlapi
> Advantage: consistent with another groups (like servletapi); better
> separation between specification (JSTL) and implementation (Jakarta
> Standard Taglibs)
> Disadvantage: jar is created by another project (there is no JSTL
> project on Jakarta/ASF), replication of existing directory ('jstl');
> ugly name
> [ ] +0 Doesn't matter for me
> Notice that this is note a typical committer-issue-vote (it's not even
> totally related to the Maven project itself), but I rather listen your
> opinions now then decide the structure myself and have to handle the
> consequences later (specially because we cannot change it once it's
> uploaded to ibiblio).
You can copy later, but you can't remove anything. The deprecation idea is probably
something that will be more feasible in the maven 2 timeframe as there could be an
application handling the repository instead of a flat file system.
Cheers,
Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1412) command line -D options seemingly ignored
The following comment has been added to this issue: Author: Carlos Sanchez Created: Tue, 3 Aug 2004 10:11 AM Body: It would be helpful if the -X output has a ClassCastException to see if it is related to other previous issues - View this comment: http://jira.codehaus.org/browse/MAVEN-1412?page=comments#action_22684 - View the issue: http://jira.codehaus.org/browse/MAVEN-1412 Here is an overview of the issue: - Key: MAVEN-1412 Summary: command line -D options seemingly ignored Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0 Assignee: Reporter: David Blevins Created: Tue, 3 Aug 2004 2:04 AM Updated: Tue, 3 Aug 2004 10:11 AM Environment: $ uname -a CYGWIN_NT-5.1 Pepe 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin $ $JAVA_HOME/bin/java -version java version "1.4.2_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b01) Java HotSpot(TM) Client VM (build 1.4.2_03-b01, mixed mode) Description: Trying to run the Geronimo build with -Dmaven.test.failure.ignore=true does not work on the command line. This option does work when added to the project.properties file. Editing the maven shell script to echo the java command rather than execute yeilds this output: /program_files/jdk1.4.2/bin/java -Xmx256m -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djava.endorsed.dirs=C:\program_files\jdk1.4.2\lib\endorsed;C:\program_files\maven-1.0\lib\endorsed -classpath C:\program_files\maven-1.0/lib/forehead-1.0-beta-5.jar -Dforehead.conf.file=C:\program_files\maven-1.0/bin/forehead.conf -Dtools.jar=C:\program_files\jdk1.4.2/lib/tools.jar -Dmaven.home=C:\program_files\maven-1.0 com.werken.forehead.Forehead -Dmaven.test.failure.ignore=true - 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-1412) command line -D options seemingly ignored
The following comment has been added to this issue: Author: Brett Porter Created: Tue, 3 Aug 2004 10:01 AM Body: -X output may not be helpful, but you can check it. -D options work for me... and should win over build.properties settings, but can you check whether it is set there? (On windows, this is probably in c:\documents and settings\dblevins\build.properties) - View this comment: http://jira.codehaus.org/browse/MAVEN-1412?page=comments#action_22683 - View the issue: http://jira.codehaus.org/browse/MAVEN-1412 Here is an overview of the issue: - Key: MAVEN-1412 Summary: command line -D options seemingly ignored Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0 Assignee: Reporter: David Blevins Created: Tue, 3 Aug 2004 2:04 AM Updated: Tue, 3 Aug 2004 10:01 AM Environment: $ uname -a CYGWIN_NT-5.1 Pepe 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin $ $JAVA_HOME/bin/java -version java version "1.4.2_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b01) Java HotSpot(TM) Client VM (build 1.4.2_03-b01, mixed mode) Description: Trying to run the Geronimo build with -Dmaven.test.failure.ignore=true does not work on the command line. This option does work when added to the project.properties file. Editing the maven shell script to echo the java command rather than execute yeilds this output: /program_files/jdk1.4.2/bin/java -Xmx256m -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djava.endorsed.dirs=C:\program_files\jdk1.4.2\lib\endorsed;C:\program_files\maven-1.0\lib\endorsed -classpath C:\program_files\maven-1.0/lib/forehead-1.0-beta-5.jar -Dforehead.conf.file=C:\program_files\maven-1.0/bin/forehead.conf -Dtools.jar=C:\program_files\jdk1.4.2/lib/tools.jar -Dmaven.home=C:\program_files\maven-1.0 com.werken.forehead.Forehead -Dmaven.test.failure.ignore=true - 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: (MPANNOUNCEMENT-9) Add a goal to send the announcement by mail to a list of email addresses
The following issue has been updated: Updater: Felipe Leme (mailto:[EMAIL PROTECTED]) Date: Tue, 3 Aug 2004 9:41 AM Comment: I couldn't send a message from my SMTP server at work because I wasn't sending the HELO message. So, here is yet another patch, this time using a maven property to set the host to be used in the HELO message (which by default is localhost) Changes: Attachment changed to yet_another_patch.zip - For a full history of the issue, see: http://jira.codehaus.org/browse/MPANNOUNCEMENT-9?page=history - View the issue: http://jira.codehaus.org/browse/MPANNOUNCEMENT-9 Here is an overview of the issue: - Key: MPANNOUNCEMENT-9 Summary: Add a goal to send the announcement by mail to a list of email addresses Type: New Feature Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-announcement-plugin Versions: 1.2 Assignee: Vincent Massol Reporter: Vincent Massol Created: Thu, 8 Jul 2004 4:16 AM Updated: Tue, 3 Aug 2004 9:41 AM Description: - 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: [VOTE] Options for the Jakarta Taglibs Maven repository
Felipe Leme wrote:
Hi all,
As we haven't reached a common sense on how to name the groups, I think
we should vote for it. The issues are:
1.Multiple directories x one directory:
[ ] +1 Put everything in one directory (such as jakarta-taglibs)
Advantage: less groups on ibiblio
Disadvantage: the group is going to be huge (around 30-80 files on
each artifact sub-dir)
[ ] +1 Create one directory for group (ex: taglibs-standard,
taglibs-request).
Advantages: easier to locate artifacts; consistent with the way
Jakarta Commons is organized
+1 The decision on which structure to use should be more dependent on
the "type" of group structure you have. If you expect the various
"subgroups" of your group to be releasing on separate schedules and/or
have new sub-groups created, then I would recommend you place the
artifacts into their own project directories. This way the various
groups can maintain separate directory structures with separate
contents, which will be easier to manage.
[ ] +0 Doesn't matter for me
2.(In case one directory wins previous poll)
[ ] +1 Use new directory 'jakarta-taglibs
Advantage: better identify which taglibs that group refers too
Disadvantage: replication of existing directory ('taglibs')
+1 just because an old directory exists, doesn't mean that you as the
individual managing taglibs maven release can't choose a new one, your
the "canonical" source for these files. 'taglibs' is very generic.
[ ] +1 Use existing directory 'taglibs'
Advantage: no replication of existing directory
Disadvantage: name is too generic
-1 I agree, we see this problem arise in other areas of the repository,
if it can be cleaned out, (or deprecated as the other thread suggests,
that would be good)
[ ] +0 Doesn't matter for me
3.Where to put jstl.jar
[ ] +1 Wherever standard.jar is
Advantage: jstl.jar is created by Jakarta Standard Taglibs
Disadvantage: it's a JCP API of its own; replication of existing
directory ('jstl')
[ ] +1 On existing group jstl
Advantage: no replication of existing directory; better separation
between specification (JSTL) and implementation (Jakarta Standard
Taglibs)
Disadvantage: jar is created by another project (there is no JSTL
project on Jakarta/ASF); inconsistent with another groups (like
servletapi)
+1 this sounds good, JSTL is fairly unique in the community, I don't
beleive there will be any naming clashes.
[ ] +1 On new group jstlapi
Advantage: consistent with another groups (like servletapi); better
separation between specification (JSTL) and implementation (Jakarta
Standard Taglibs)
Disadvantage: jar is created by another project (there is no JSTL
project on Jakarta/ASF), replication of existing directory ('jstl');
ugly name
[ ] +0 Doesn't matter for me
Notice that this is note a typical committer-issue-vote (it's not even
totally related to the Maven project itself), but I rather listen your
opinions now then decide the structure myself and have to handle the
consequences later (specially because we cannot change it once it's
uploaded to ibiblio).
Regards,
Felipe
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
Oops, forgot my votes: > 1.Multiple directories x one directory: > [X ] +1 Create one directory for group (ex: taglibs-standard, > taglibs-request). > Advantages: easier to locate artifacts; consistent with the way > Jakarta Commons is organized > 3.Where to put jstl.jar > [X] +1 On existing group jstl > Advantage: no replication of existing directory; better separation > between specification (JSTL) and implementation (Jakarta Standard > Taglibs) For this one, I changed my mind after Carlos' messages... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
On Tue, 2004-08-03 at 03:44, Nicolas De Loof wrote: > MAVEN ENHANCEMENT SUGGESTION: > > Could'nt we have an automatic way to 'deprecate' some artifcat location, giving the > alternative group/artifactId to be > used ? It may been displayed by maven as a warning when downloading dependencies. > For example, a stamp file "groupid/type/artifactid-version.deprecated" may be a text > file containing the warning message > that maven can search when it downloads an artifact. That would be nice, and I guess it wouldn't be hard to implement... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Options for the Jakarta Taglibs Maven repository
On Tue, 2004-08-03 at 02:21, John Casey wrote: > Just curious, but are you in control of the jakarta-taglibs builds? Yes, I am one of the committers. > understand if you're pinging the maven-dev list for best practices (I Agree, but I'm not subscribed there (and started the thread here). Could you please forward it for me? > jakarta-taglibs organization on ibiblio, you're talking to the wrong > people...the taglibs people are able to control that. That thread started a couple of months ago, but just now I've taking the steps to make it available (the original post suggested one directory only, but I created many and nobody complained): http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=656477 In other words, it doesn't really matter for us (taglibs developers), this is more concerned to Maven users and ibiblio maintainers. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVEN-1412) command line -D options seemingly ignored
The following comment has been added to this issue: Author: Carlos Sanchez Created: Tue, 3 Aug 2004 5:20 AM Body: Could you post the output of running maven with the -X option - View this comment: http://jira.codehaus.org/browse/MAVEN-1412?page=comments#action_22678 - View the issue: http://jira.codehaus.org/browse/MAVEN-1412 Here is an overview of the issue: - Key: MAVEN-1412 Summary: command line -D options seemingly ignored Type: Bug Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven Versions: 1.0 Assignee: Reporter: David Blevins Created: Tue, 3 Aug 2004 2:04 AM Updated: Tue, 3 Aug 2004 5:20 AM Environment: $ uname -a CYGWIN_NT-5.1 Pepe 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin $ $JAVA_HOME/bin/java -version java version "1.4.2_03" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b01) Java HotSpot(TM) Client VM (build 1.4.2_03-b01, mixed mode) Description: Trying to run the Geronimo build with -Dmaven.test.failure.ignore=true does not work on the command line. This option does work when added to the project.properties file. Editing the maven shell script to echo the java command rather than execute yeilds this output: /program_files/jdk1.4.2/bin/java -Xmx256m -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djava.endorsed.dirs=C:\program_files\jdk1.4.2\lib\endorsed;C:\program_files\maven-1.0\lib\endorsed -classpath C:\program_files\maven-1.0/lib/forehead-1.0-beta-5.jar -Dforehead.conf.file=C:\program_files\maven-1.0/bin/forehead.conf -Dtools.jar=C:\program_files\jdk1.4.2/lib/tools.jar -Dmaven.home=C:\program_files\maven-1.0 com.werken.forehead.Forehead -Dmaven.test.failure.ignore=true - 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] Closed: (MPMULTIPROJECT-38) multiproject:site doesn't generate overview page with links to projects
Message: The following issue has been closed. - View the issue: http://jira.codehaus.org/browse/MPMULTIPROJECT-38 Here is an overview of the issue: - Key: MPMULTIPROJECT-38 Summary: multiproject:site doesn't generate overview page with links to projects Type: Bug Status: Closed Priority: Major Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-multiproject-plugin Assignee: dion gillard Reporter: Michael Mattox Created: Thu, 17 Jun 2004 9:40 AM Updated: Tue, 3 Aug 2004 5:18 AM Environment: maven 1.0rc3, win2k, jsdk1.4.2 Description: I don't know what happened, but now multiproject:site doesn't generate overview page with links to projects. All the projects are there under the multiproject dir, but there is no overview page. I've spent hours and hours on this and I can't figure it out. When I use multiproject.includes=**/project.xml it doesn't produce an overview. When I list the projects it does. - 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: (MPMULTIPROJECT-38) multiproject:site doesn't generate overview page with links to projects
The following comment has been added to this issue: Author: Michael Mattox Created: Tue, 3 Aug 2004 4:12 AM Body: It hasn't happened since the upgrade to Maven 1.0. I don't know why or any more details because it was not consistent. It stopped generating the overview page and then started again. The cycle continued and I couldn't find out why. But it seems to be OK in Maven 1.0. Please cancel this issue. Thanks Michael - View this comment: http://jira.codehaus.org/browse/MPMULTIPROJECT-38?page=comments#action_22677 - View the issue: http://jira.codehaus.org/browse/MPMULTIPROJECT-38 Here is an overview of the issue: - Key: MPMULTIPROJECT-38 Summary: multiproject:site doesn't generate overview page with links to projects Type: Bug Status: Open Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-multiproject-plugin Assignee: dion gillard Reporter: Michael Mattox Created: Thu, 17 Jun 2004 9:40 AM Updated: Tue, 3 Aug 2004 4:12 AM Environment: maven 1.0rc3, win2k, jsdk1.4.2 Description: I don't know what happened, but now multiproject:site doesn't generate overview page with links to projects. All the projects are there under the multiproject dir, but there is no overview page. I've spent hours and hours on this and I can't figure it out. When I use multiproject.includes=**/project.xml it doesn't produce an overview. When I list the projects it does. - 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: (MPHIBERNATE-10) maven-hibernate ignores the "config" attribute
The following comment has been added to this issue: Author: Henning Schmiedehausen Created: Tue, 3 Aug 2004 3:14 AM Body: You should load _either_ the XML file _or_ the properties file. Loading both will result in "duplicate imports". I use this patch for a large(ish) project and it works fine. Regards Henning - View this comment: http://jira.codehaus.org/browse/MPHIBERNATE-10?page=comments#action_22673 - View the issue: http://jira.codehaus.org/browse/MPHIBERNATE-10 Here is an overview of the issue: - Key: MPHIBERNATE-10 Summary: maven-hibernate ignores the "config" attribute Type: Bug Status: Unassigned Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-hibernate-plugin Fix Fors: 1.2 Assignee: Reporter: Henning Schmiedehausen Created: Thu, 22 Jul 2004 3:17 PM Updated: Tue, 3 Aug 2004 3:14 AM Description: Hibernate allows you to use an xml config file instead of the regular properties file. Everything is almost in place, however I needed the attached patch to make it actually work. The patch to plugin.jelly brings the property to the tag and the Java code patch allows Hibernate to open the correct file. Please apply - 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]
