[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (40 issues) Subscriber: mavendevlist Key Summary MEV-523 prefuse -sources.jar is missing http://jira.codehaus.org/browse/MEV-523 MEV-520 retroweaver 1.2.4 jar is corrupt http://jira.codehaus.org/browse/MEV-520 MEV-513 Invalid POM: aspectwerkz/aspectwerkz-core http://jira.codehaus.org/browse/MEV-513 MEV-511 org.apache.struts:struts2-tiles-plugin:2.0.6 contains a SNAPSHOT deps http://jira.codehaus.org/browse/MEV-511 MEV-504 Jetty 5.1.10 and 5.1.11 missing poms http://jira.codehaus.org/browse/MEV-504 MEV-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 MEV-499 Latest version of clover plugin in maven.metadata.xml http://jira.codehaus.org/browse/MEV-499 MEV-498 javax.xml.ws:jaxws-api:2.1 is bad http://jira.codehaus.org/browse/MEV-498 MEV-36 Exo POM(s) missing dependency versions http://jira.codehaus.org/browse/MEV-36 MEV-483 Still invalid deps in 3.2.1, 3.2.2, 3.2.3, 3.2.4 http://jira.codehaus.org/browse/MEV-483 MEV-457 Geronimo jar fails to download http://jira.codehaus.org/browse/MEV-457 MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib http://jira.codehaus.org/browse/MEV-352 MEV-427 relocate ehcache:ehcache to net.sf.ehcache http://jira.codehaus.org/browse/MEV-427 MEV-471 javax.xml:jsr173:1.0 should be relocated to javax.xml.bind:jsr173_api:1.0 http://jira.codehaus.org/browse/MEV-471 MEV-469 jaxb-api available with two different groupIds http://jira.codehaus.org/browse/MEV-469 MEV-375 Relocate xpp to xpp3 http://jira.codehaus.org/browse/MEV-375 MEV-443 Several projects have maven-metadata.xml files that are missing released versions http://jira.codehaus.org/browse/MEV-443 MEV-461 Missing pom for commons-logging-api-1.1 http://jira.codehaus.org/browse/MEV-461 MEV-454 testng-spring has a invalid dependency on testng. http://jira.codehaus.org/browse/MEV-454 MEV-449 lucene 1.9.1 JAR is hosed. http://jira.codehaus.org/browse/MEV-449 MEV-448 xmlrpc POM should include commons-codec http://jira.codehaus.org/browse/MEV-448 MEV-441 Several projects have bad maven-metadata.xml files that are screwing up dependencies with version range feature http://jira.codehaus.org/browse/MEV-441 MEV-20 clean up bad IDs in the repository http://jira.codehaus.org/browse/MEV-20 MEV-436 JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 it needs connector-1.5. http://jira.codehaus.org/browse/MEV-436 MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded variables http://jira.codehaus.org/browse/MEV-296 MEV-405 pom for cactus:cactus:13-1.7.2 http://jira.codehaus.org/browse/MEV-405 MEV-404 pom for cactus:cactus-ant:13-1.7.2 http://jira.codehaus.org/browse/MEV-404 MEV-401 Incoherences / duplication between javax.xml and com.sun.xml http://jira.codehaus.org/browse/MEV-401 MEV-334 Stax POM points to an invalid XMLBeans dependency http://jira.codehaus.org/browse/MEV-334 MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit) http://jira.codehaus.org/browse/MEV-364 MEV-356 Missing dep on jboss-common in jbossmq-client & jnp-client 4.0.2 http://jira.codehaus.org/browse/MEV-356 MEV-351 xmlc-xerces-2.2.7.1.jar is unnecessary and xmlc-apis.jar is required. http://jira.codehaus.org/browse/MEV-351 MEV-330 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's required for plain ol' JSPs http://jira.codehaus.org/browse/MEV-330 MEV-325 Description of jaxb-api 1.0.1 is wrong http://jira.codehaus.org/browse/MEV-325 MEV-320 Hibernate 3.1.x POMs pull in Sun jars http://jira.codehaus.org/browse/MEV-320 MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype http://jira.codehaus.org/browse/MEV-201 MEV-48 openejb poms http://jira.codehaus.org/browse/MEV-48 MEV-45 Full list of poms that doesn't respect the m2 format http://jira.codehaus.org/browse/MEV-45 MEV-33 XOM POM references xercesImpl v.2.2.1 which does not exist in repo http://jira.codehaus.org/browse/MEV-33 MEV-31 XOM POM references xmlParserAPIs v2.6.1 which is not in the repo http://jira.codehaus.org/browse/MEV-31 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Uploads
Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (8 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1483Please synchronize the jDTAUS repository http://jira.codehaus.org/browse/MAVENUPLOAD-1483 MAVENUPLOAD-1576Xanot (XML to Object mapper). Central repository upload request. http://jira.codehaus.org/browse/MAVENUPLOAD-1576 MAVENUPLOAD-1454Upload of rmock 2.0.0. Group already exists. http://jira.codehaus.org/browse/MAVENUPLOAD-1454 MAVENUPLOAD-1554antlr-3.0 and antlr-runtime-3.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1554 MAVENUPLOAD-1574Upload Hibernate Entity Manager 3.3.1.ga http://jira.codehaus.org/browse/MAVENUPLOAD-1574 MAVENUPLOAD-1575Upload Hibernate Validator 3.0.0.ga http://jira.codehaus.org/browse/MAVENUPLOAD-1575 MAVENUPLOAD-1552Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1552 MAVENUPLOAD-1405Eclipse SWT version 3.2.1 linux http://jira.codehaus.org/browse/MAVENUPLOAD-1405 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[result] Release Portlet Archetype 1.0.1 and Archetype parents
Binding +1 votes: brett, snicoll, vsiveton Non-binding +1 votes: oching I'll do the release. On 25/05/2007, at 3:40 PM, Brett Porter wrote: Hi, The 1.0 release of the portlet archetype doesn't work at all, but Franz has patched it up and it's useful now. There are no open issues for this archetype, so I'd like to release 1.0.1, and the dependant parent POMs. To test it, build it and run something like: mvn archetype:create -DartifactId=ARCHETYPE-40 - DarchetypeArtifactId=maven-archetype-portlet - DarchetypeVersion=1.0.1 -DgroupId=test -DremoteRepositories=http:// people.apache.org/~brett/stage-repo Stage repo: http://people.apache.org/~brett/stage-repo Tags: http://svn.apache.org/repos/asf/maven/archetype/tags/maven- archetype-parent-2/ http://svn.apache.org/repos/asf/maven/archetype/tags/maven- archetype-bundles-3/ http://svn.apache.org/repos/asf/maven/archetype/tags/maven- archetype-portlet-1.0.1/ [ ] +1 [ ] 0 [ ] -1 Cheers, Brett - 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: [proposal] Change project names for M1 plugins in JIRA
Done! Dennis Lundberg wrote: Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype packaging
Hi, 2007/5/30, Kenney Westerhof <[EMAIL PROTECTED]>: Hi, That kind of metadata is not handled by packaging, but by the artifact manager. What do you need this for? If it's to automatically list all available archetypes, that would be great. You guessed \o/ Currently, the selection mojo is based on the same mecanism as the maven plugins. In interractive mode, it: - ask for a group from a list (org.apache.maven.archetypes and org.codehaus.mojo.archetypes) - retrieves the group metadata - ask for an archetype found in the metadata (construct a list) - retrieves the artifact metadata - ask for the version found in the metadata (construct a list) I would like to have a new maven-archetype packaging (currently working on) Concerning the issue of packaging, metadata and archetype selection from lists, i have some options: - mimics the plugin metadatas (in groups) but changing the name of the metadata file in repo - using the plugin metadatas, this implies to have plugins and archetypes in separate groups - have a per repository registry (xml or other) that holds the archetypes metadatas for the whole repository this implies to have a way to 'merge' information from many repos in the local repo (to be used offline) WDYT? Raphaël We should generalize that by having a special kind of metadata in special groups, like org/apache/maven/metadata/(metadata-group)/ or similar, so we can centrally store package handlers, plugin metadata, archetypes etc. spanning different groupId's. There'd be a central place (groupid) in each repository for storing that information. If you need this for something totally different, then n/m the above, just wanted to pitch this in since it's been on my mind for a while now. -- Kenney Raphaël Piéroni wrote: > Hi > > if i would create a new packaging for archetypes, > what is the way (i don't need doco link about lifecycle hook > of a mojo, i already know it ;) ) > to have a specific metadata uploaded as long with the > artifact during the install and deploy phases. > > My point is how to create metadata and how to > have them automagically uploaded; > > for a group, say org.apache.maven.archetypes, > and an archetype, quickstart-archetype, at version 1.0 > i need a metadata in the org/apache/maven/archetypes > directory, and in org/apache/maven/archetypes/quickstart-archetype > just like the maven-plugins. > > Many thanks for any help. > > Regards > > Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Change project names for M1 plugins in JIRA
+1 - Joakim John Casey wrote: +1 On May 30, 2007, at 11:27 AM, Dennis Lundberg wrote: Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Change project names for M1 plugins in JIRA
+1 -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 10:27 AM To: dev@maven.apache.org Subject: [proposal] Change project names for M1 plugins in JIRA Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - 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: [proposal] Change project names for M1 plugins in JIRA
+1 On 5/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: +1 -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 1:01 PM To: Maven Developers List Subject: Re: [proposal] Change project names for M1 plugins in JIRA +1 On May 30, 2007, at 11:27 AM, Dennis Lundberg wrote: > Hi > > We get some JIRA issues for the M1 plugins that really belongs to the > M2 plugins. To help get these issues into the correct JIRA project > from the start, I propose that we change the names of the JIRA > projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA > Plugin". > > Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". > > I am willing to do the actual changes if you like this proposal. > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Change project names for M1 plugins in JIRA
+1 -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 30, 2007 1:01 PM To: Maven Developers List Subject: Re: [proposal] Change project names for M1 plugins in JIRA +1 On May 30, 2007, at 11:27 AM, Dennis Lundberg wrote: > Hi > > We get some JIRA issues for the M1 plugins that really belongs to the > M2 plugins. To help get these issues into the correct JIRA project > from the start, I propose that we change the names of the JIRA > projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA > Plugin". > > Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". > > I am willing to do the actual changes if you like this proposal. > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Change project names for M1 plugins in JIRA
+1 On May 30, 2007, at 11:27 AM, Dennis Lundberg wrote: Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john
Re: release plugin dependency resolution (was: svn commit: r502089 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java)
On 29/05/07, Brett Porter <[EMAIL PROTECTED]> wrote: Heh. Nice catch! Can you get that into JIRA? Done: http://jira.codehaus.org/browse/MNG-3015 > Sure, I was envisaging that it could be fixed in 2.0.7 after which the > release plugin could have 2.0.7 as a prerequisite. Still an unreleased version :) I meant: fix in 2.0.7-SNAPSHOT; release 2.0.7; depend on 2.0.7 - but I'm sure you got my drift already ;) >> I also think that change would be for 2.1 anyway. > > Even though it's really a bug fix? I'm not sure it's going to be a simple fix - it's really going to need a functional enhancement. If you consider the other dependencies as being present, you still need to ensure the goal is running in a phase when the dependencies will actually exist. If install wasn't called, then that won't be the case (or at least package if the packaged artifacts can be used from the target directory). Yeah, it's probably not going to be easy. I've created a failing IT and raised this issue to keep track of it: http://jira.codehaus.org/browse/MNG-3023 Feel free to sanity check it if you've got time. On 29/05/07, Brett Porter <[EMAIL PROTECTED]> wrote: I'm not sure I understand why 2.0.6/MNG-1577 is required to simulate @rDR - other plugins already do it on prior versions. However, I'm still not in favour of the release plugin depending on an unreleased version of Maven (even if the root problem can be fixed in 2.0.7). MNG-1577 introduced an API change with MavenProject.getManagedVersionMap, which is used by the artifact resolving code I'll be simulating in DefaultPluginManager.resolveTransitiveDependencies. Surely MNG-1577 will affect the resolved versions used in the release pom, so we can't use the 2.0 API and expect MNG-1577 style results? Yes, I see what you mean. I'm not sure putting them into the managed dependencies map will help, as they still won't resolve if they aren't installed. So the sequence might need to be: - resolve the project dependencies, filtering out the reactor projects - add the reactor projects to the list of resolved artifacts - iterate through the reactor projects and resolve each's dependencies (again filtering the reactor projects) and add to the list of resolved artifacts. Does that make sense? Possibly, I'll consider it properly tomorrow and let you of the next problem ;) Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Change project names for M1 plugins in JIRA
See http://jira.codehaus.org/browse/MPA-43 You have my +1 if you want to go for it... :) -Lukas Dennis Lundberg wrote: Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Change project names for M1 plugins in JIRA
+1 On 30 May 07, at 11:27 AM 30 May 07, Dennis Lundberg wrote: Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] Change project names for M1 plugins in JIRA
Hi We get some JIRA issues for the M1 plugins that really belongs to the M2 plugins. To help get these issues into the correct JIRA project from the start, I propose that we change the names of the JIRA projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA Plugin". Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin". I am willing to do the actual changes if you like this proposal. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Archetype packaging
Hi, That kind of metadata is not handled by packaging, but by the artifact manager. What do you need this for? If it's to automatically list all available archetypes, that would be great. We should generalize that by having a special kind of metadata in special groups, like org/apache/maven/metadata/(metadata-group)/ or similar, so we can centrally store package handlers, plugin metadata, archetypes etc. spanning different groupId's. There'd be a central place (groupid) in each repository for storing that information. If you need this for something totally different, then n/m the above, just wanted to pitch this in since it's been on my mind for a while now. -- Kenney Raphaël Piéroni wrote: Hi if i would create a new packaging for archetypes, what is the way (i don't need doco link about lifecycle hook of a mojo, i already know it ;) ) to have a specific metadata uploaded as long with the artifact during the install and deploy phases. My point is how to create metadata and how to have them automagically uploaded; for a group, say org.apache.maven.archetypes, and an archetype, quickstart-archetype, at version 1.0 i need a metadata in the org/apache/maven/archetypes directory, and in org/apache/maven/archetypes/quickstart-archetype just like the maven-plugins. Many thanks for any help. Regards Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Remote repositories not displayed anymore
Yep - I just filed a bug before it earlier. On 30/05/2007, at 8:24 PM, Fabrice Bellingard wrote: Hi, I've updated my local copy of Archiva this morning and built it, and it seems that Archiva has problems to load its configuration as I get a "There are no remote repositories configured yet" when I go to "Administration -> Repositories" (whereas remote repositories do exist in archiva.xml). This was working properly yesterday. Do you have the same behaviour? Fabrice.
Re: [vote] Release Portlet Archetype 1.0.1 and Archetype parents
Sorry for the delay, here is my +1 Review the license header in the archetype-resources for the next release. Vincent 2007/5/25, Brett Porter <[EMAIL PROTECTED]>: Hi, The 1.0 release of the portlet archetype doesn't work at all, but Franz has patched it up and it's useful now. There are no open issues for this archetype, so I'd like to release 1.0.1, and the dependant parent POMs. To test it, build it and run something like: mvn archetype:create -DartifactId=ARCHETYPE-40 - DarchetypeArtifactId=maven-archetype-portlet -DarchetypeVersion=1.0.1 -DgroupId=test -DremoteRepositories=http://people.apache.org/~brett/ stage-repo Stage repo: http://people.apache.org/~brett/stage-repo Tags: http://svn.apache.org/repos/asf/maven/archetype/tags/maven-archetype- parent-2/ http://svn.apache.org/repos/asf/maven/archetype/tags/maven-archetype- bundles-3/ http://svn.apache.org/repos/asf/maven/archetype/tags/maven-archetype- portlet-1.0.1/ [ ] +1 [ ] 0 [ ] -1 Cheers, Brett - 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]
