Re: DB schema migration
Hi, On 4/25/07, Trygve Laugstøl [EMAIL PROTECTED] wrote: Stephane Nicoll wrote: Can I be sure at least that the DB model won't change as from alpha-1? If so I can maybe drop completely my database and recreate my projects. We've been over this before, but I'll repeat: Alphas give no guarantee of API (including DB) stability. Hopefully it won't change too much, but it should in no way stop the developers from breaking stuff. I agree. What is important here is the ability to dump the database to an external DB file (xml would be a natural choice) which can be read by a newer Continuum. As soon as this is in place, I'll migrate. Cheers, Stéphane Hopefully 1.1 will be pretty stable so it can be released ASAP and bugs can be fixed on a 1.1.x branch. -- Trygve Thanks, Stéphane On 4/23/07, Brett Porter [EMAIL PROTECTED] wrote: This was one of the things I was going to try and have done before alpha-1 - I just forgot. Erik - the problem in upgrading is the changes in private tables between versions of jpox that we hadn't given explicit names to. We'd probably appreciate most help in future proofing our jpox use a bit more in case it's internal schema changes again. I already have the tools to do an xml export of the old tables, it just needs to somehow be set to run in dump mode using the old jpox, and import using the new one. I'll look at that during ApacheCon, I think. If anyone else wants to take the task while I'm on holidays, let me know... we should also make the tool work with 1.0.3 databases if possible. This is definitely one for the release notes, btw. alpha-1 will not work with 1.0.3 (or earlier 1.1 snapshot) databases. - Brett On 22/04/2007, at 2:10 PM, Erik Bengtson wrote: If you guys need some tooling from JPOX, let me know and I could plan to implement some kind of export to XML, and import from XML. In between export/import you could apply Xqueries to transform data to match the new schema Quoting Stephane Nicoll [EMAIL PROTECTED]: Hi, I'm currently running a 1.1-SNAPSHOT from February which runs ok except a few minor issues. I'd like to upgrade to 1.1 alpha 1 as soon as it's out to provide feedback co. Last time I tried to upgrade, I had to revert because the model schema has changed and it was really difficult to update my existing data. Is there something scheduled for alpha1 regarding this (at least a manual procedure to upgrade my schema if necessary). Thanks, Stéphane
Vivek Nakeesan is out of the office.
I will be out of the office starting 25/04/2007 and will not return until 26/04/2007. I will respond to your message when I return.
Re: Archetypes - Question about languages and file extensions
2007/4/25, Brett Porter [EMAIL PROTECTED]: On 24/04/2007, at 9:29 PM, Raphaël Piéroni wrote: My questions are: - apart from java, groovy, aspectj, csharp, what are the common directory names where files with packaging ability are located? Wouldn't this be anything under main/ or test/ ? src/main/java is packaged but src/main/webapp is not - which files extension represent text files and which represent binary files? how to store such a huge list? Is it better to instead look at the content of the file to determine this? This seems like a good general purpose IO utility if it doesn't already exist in another library. jmimemagic seems to do some work, but i cant see where to find some usable javadoc on it I think i will leave those definitions to the user which will provide -Dlanguages and --Dfiltered properties with meaningfull defaults. Raphaël - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Archetype] branching question
2007/4/25, Brett Porter [EMAIL PROTECTED]: Sorry, I don't quite understand this? Are you saying it's just incompatible with what's in there already, or this now diverges from compatibility with the current version? Nope I had incompatibility between my first descriptor proposition and my second. It is solved for now. i had made a branch in the code not in the SCM. Raphaël I think it was the former, in which case you shouldn't need to do anything - you can use the revision number to go back to, but since it's not in use yet it's ok to make those breaking changes. Hope I got that right. - Brett On 17/04/2007, at 8:51 PM, Raphaël Piéroni wrote: Hi, With the archetypeng stuff, i think i have reached a point in which i need advice. For what i can see, the current code seems useable. I am currently refactoring the proposed descriptor. This change will be incompatible with the current proposition, which mimics and enchance the actual behaviour. I think i need to reprensent this changing in the SCM, but i can't figure the right way: a) create a branch in the mojo repository (but the current code is in the sandbox) b) tag by hand a 0.1-alpha-1 version (with lazy concensus vote) and stay in the sandbox c) use the release plugin to release as version (idem vote) and stay in the sandbox I dislike c, and have a light preference for b. Thanks in advance for any answer. Regards, Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon EU
Brett Porter [EMAIL PROTECTED] writes: Hi, Hello, Any other thoughts? Interest from the folks attending in anything in particular? I am far from being a regular contributor to maven, for lack of time and lack of the big picture (hence lack of time to construct it myself from code source), maybe also from lack of skill. My main interest in ApacheCon is then to meet the people behind maven who have this big picture in their head, to understand the choices, rationales and plans behind what maven is and will be, so that I could feel more comfortable in doing some hacking on it. I am the kind of person that needs to understand what's under the hood to start working on something. More specifically, I am interested in discussing/advancing/learning on the following topics: - unified reporting system that would allow easier dashboards, statistics collection, report generation... (already talked about it a while ago) - maven test execution and reporting system (ie. surefire), at all levels: unit, integration, functional. There seems to be a lot of open issues without assignees, and I would like to provide manpower on these and to work on a more general view of automated testing. - maven documentation system (ie. doxia) - Jason Van Zyl Enterprise maven initiative. See you next week, Regards. -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Conflict resolvers
On 25/04/07, Brett Porter [EMAIL PROTECTED] wrote: Cool, I'll take a look - since there seems to be a lot of talk about maven-artifact right now, maybe this could be added to a list of things to discuss while folks are f2f for the upcoming conferences. I'll send a separate mail. Thanks Brett. I've attached a subsequent patch which remedies (1) and (2). Let me know how you'd like to take this forward, until then I'll move onto something else. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
Result of the vote: +1 Binding: Brian, Vincent S., Jesse, Stéphane +1 Non Binding: Jochen Wiedmann, Daniel Kulp, Niall Pemberton I'll proceed with the release. Thanks, Stéphane On 4/21/07, Stephane Nicoll [EMAIL PROTECTED] wrote: Hi, I'd like to release the maven-source-plugin 2.0.3 The staging bits are available here: http://people.apache.org/~snicoll/maven-staging/repo/org/apache/maven/plugins/maven-source-plugin/2.0.3/ The release notes: ** Bug * [MSOURCES-6] - Sources plugin ignores resource includes/excludes * [MSOURCES-12] - size of source jar grows and grows ** Improvement * [MSOURCES-11] - When source plugin is used, it should make sure it is invoked during install Vote open for 72hours. My +1 Stéphane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dep to same artifact in different versions
Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M1][vote] release plugins : idea 1.7, jalopy 1.5.1, jar 1.8.1, javadoc 1.9, multichanges 1.3, plugin 1.7.1
+1 Stéphane On 4/24/07, Lukas Theussl [EMAIL PROTECTED] wrote: +1 -Lukas Arnaud HERITIER wrote: Here is a new list of plugins to release for maven 1.x. -- IDEA 1.7 -- Changes in this version include : New Features: o Autodetect which version control system to use Fixes MPIDEA-43. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-idea-plugin -Dversion=1.7-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/idea/ -- JALOPY 1.5.1 -- Changes in this version include : New Features: o Add a property that controls the source code encoding. Fixes MPJALOPY-12. Thanks to Joachim Bader. Changes: o Upgrade plexus-utils to version 1.0.5 Fixes MAVEN-1803. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jalopy-plugin -Dversion=1.5.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jalopy/ -- JAR 1.8.1 -- Changes in this version include : Changes: o Change the default repository to http://repo1.maven.org/maven/ for dependencies url in the manifest. Fixes MAVEN-1789. o Update to velocity 1.5. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-jar-plugin -Dversion=1.8.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/jar/ -- JAVADOC 1.9 -- Changes : Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-javadoc-plugin -Dversion=1.9-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/javadoc/ -- MULTICHANGES 1.3 -- Changes in this version include : New Features: o New page to describe the next releases. o New RSS feed for releases. Changes: o New internal format to store information about releases. o Remove usage of the deprecated dependency-handle tag. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-multichanges-plugin -Dversion=1.3-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/multichanges/ -- PLUGIN 1.7.1 -- Changes in this version include : Fixed bugs: o assert:assertPluginAvailable : Fix error (NoSuchElementException) if the minimum release number has less elements than the version number installed. Changes: o Don't check that a given plugin version is available in the bootstrap. o Update dependencies to unify them between plugins. The following dependencies are updated : commons-jelly-tags-interaction v1.0 to v1.1, jaxen v1.0-FCS-full to 1.1-beta-9. The following dependencies are removed : saxpath. o Upgrade to Xerces 2.8.0. Replace the deprecated xmlParserAPIs by xml-apis 1.3.03. Add the xml-resolver dependency for xerces. Fixes MAVEN-1753. Download : maven plugin:download -Dmaven.repo.remote=http://people.apache.org/repo/m1-snapshot-repository/, http://repo1.maven.org/maven -DgroupId=maven -DartifactId=maven-plugin-plugin -Dversion=1.7.1-SNAPSHOT Staging site : http://people.apache.org/~aheritier/staging-sites/m1-plugins/maven-1.x/plugins/plugin/ Normal voting rules, 72 hours, +1/0/-1 My +1 for all Arnaud - 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: ApacheCon EU
On 24 Apr 07, at 7:42 PM 24 Apr 07, Brett Porter wrote: Hi, I saw that Dennis, Jason, Kenney, Eric, Martin, Robert, and Arnaud B will all be at AC EU next week - is anyone else attending ApacheCon? Eric and Kenney won't be joining us, but they will be at JavaOne. The Sonatype will be coming en masse to JavaOne and we're happy to organize something there, I'll send another email about it. I've secured some working space if we want it. I think it would be good to get some time in front of a white board to go through a couple of the big issues while we have the opportunity for face time and to hack some things together. It sounds like the same opportunity will present itself at JavaOne too. Of course, we can discuss some in real time with people on IRC and bring any output back to the list so everyone gets a chance to participate. What day/time would suit people? We could throw up a quick calendar on Google that has free access and then we can see busy/free slots. Maybe the following are appropriate for AC: - anything more we can do for releases (polish up the staging stuff, incorporate RAT, ...?) - plugin integration testing and unit testing - roadmap discussion / highlighting other issues Any other thoughts? Interest from the folks attending in anything in particular? This is my rough list: - [ ] Architectural Goals for Maven 2.1 - [ ] Plugins - [ ] Refactor Plugin Manager - [ ] Removal of the Plugin Registry (done) - [ ] Load Plugin dependencies into a separate ClassRealm (done) - [ ] Plugin Execution Environment: Ability to run any version of a plugin where an environment is created which contains all the requirements for a particular version of the Plugin API - [ ] Expressions: supporting old annotations and allowing for new ones. The expression evaluator would become part of the execution environment - [ ] Reporting - [ ] Report Execution Environment: Ability to run any version of a report where an environment is created which contains all the requirements for a particular version of the Report API - [ ] Decouple reporting from core - [ ] Artifact Resolution - [ ] Graph-based artifact resolution - [ ] Decouple from Maven's core - [ ] Decouple script-based Plugins from the core - [ ] Refactor Project Builder - [ ] Pluggable model readers - [ ] A new terse format that uses attributes - [ ] Allow mixin capabilities using an import directive - [ ] Automatic parent versioning - [ ] Execution Configuration - [ ] Remove Settings from the core and make it a user facing configuration - [ ] The Embedder should be the only place Settings are dealt with - [ ] Remove from the ProfileManager: profile information can be used from the ExecutionRequest - [ ] Remove from the PluginLoader: the plugin groups can come in from the ExecutionRequest - [ ] Remove from the ExecutionRequest - [ ] Remove from the Session - [ ] Have one configuration model for request - [ ] Have one configuration model for session: session takes the request in the constructor and delegates - [ ] Domain logging - [ ] - [ ] Project/Community Issues - [ ] Surefire - [ ] Release Management - [ ] Repository Management - [ ] Documentation - [ ] Plugin Integration Testing - [ ] Integration Testing - [ ] Invoker/Verfier I'm trying to sort out a way to go from OO to Wiki as I can't work anymore with OO. That's OmniOutliner not OpenOffice (which is a terrible piece of software). Jason. - 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: [m2] Conflict resolvers
On 23 Apr 07, at 1:01 PM 23 Apr 07, Mark Hobson wrote: Hi there, I've had an initial stab at implementing ConflictResolvers and attached a patch to MNG-612. If people wouldn't mind taking a peek, I'd appreciate some feedback on the following: Not sure if you noticed the MNG-1577 debate, but much of the conflict resolution has been solved by the specification of the versions in depMan ruling out over anything. Now the cases where you are pulling in a transitive dependency that can come from two, or more, distinct subgraphs that you have not defined in your depMan is where some form of conflict resolution might come into play. I think for the most part people would want to be able to see this transitive graph and select the version, until such a time that we can say definitively that the latest version of something is compatible with everything else being used. I think we are quite a ways away from that people would probably end up locking down a version in depMan. But ultimately what is currently there must be replaced by a system that does not alter the graph while the graph is forming. By this I mean the entire graph must be resolved first and any subsequent transformation whether that be scope state changes, version alignment, and repository ordering must be done using standard graph transformation. We simply need a resolution specification and it has to be based on a graph being the fundamental unit of work. There is far too much transformation going on mid stream and it causes problems, and we lose critical information that would make deterministic choices hard if not impossible right now. It will be one of the things I will be bring up at ApacheCon and JavaOne. It is the source of greatest bewilderment to users, especially the behavior prior to MNG-1577. So I would be hesitant to apply any of these changes to trunk. Jason. 1) ConflictResolver API - is the negative/positive/zero return type sufficient, or would a boolean return type with an exception for the unresolvable state be more appropriate? 2) ArtifactCollector signature change - is this okay or will it break lots of code? If we are to maintain the original signatures, then should we really obtain a default ConflictResolver implementation via plexus? 3) New ArtifactResolver overloaded method okay? The original method implementations in DefaultArtifactResolver assume plexus default - is this okay or should it be passed in? 4) DefaultArtifactCollectorTest - many tests assume nearest conflict resolver, should these be refactored out? 5) ResolutionListener.OMIT_FOR_NEARER - should this be refactored to OMIT_FOR_CONFLICT? 6) Configuration - how do we specify a different conflict resolver implementation for the build? This does overlap with MNG-2771, but do we want a friendlier POM configuration based on role hints? e.g. buildconflictResolvernewest/conflictResolver/build. Does specifying an alternative conflict resolver in Maven's components.xml potentially cause problems outside of the build and within Maven itself? 7) Conflict resolver implementation names - newest/oldest or highest/lowest? 8) Any more conflict resolver implementations required? I've got some time allocated to work on this, so any thoughts are welcome and hopefully we can get this much-needed functionality into Maven. Cheers, Mark - 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: Dep to same artifact in different versions
On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Jason. - Jörg - 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]
JavaOne
Hi, We can certainly continue any discussions from ApacheCon at JavaOne and I have chatted with the folks at Terracotta and they would be happy to put us up for a couple days in one of their conference rooms where we can work and hold a BOF if we so choose. We can also have a conference room for a 2-3 days in succession so we have a place to continue discussions once things get started. So again we might want to put up a calendar and let people slot in their available times and I will schedule the rooms at TC. They are not that far from Moscone centre and we can easily get there quickly by cab, I can probably organize some transportation as well. Thanks to the folks at Terracotta as it's generally hard to get facilities setup where people can actually work. There's room for 10-15 people so folks should probably sign up soon, or let me know. I know for sure that myself, Eric Redmond, Kenney Westerhof, Andy Williams, John Casey, and Brett Porter will be present. If we select a date for a BOF then I can definitely schedule that. It would be a great opportunity for any users in the area to come out as it will probably be the highest concentration of core committers on record! :-) Just ping me if you're interested in attending something so I can make arrangements with Steve Harris at Terracotta. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dep to same artifact in different versions
Jason van Zyl wrote on Wednesday, April 25, 2007 2:41 PM: On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Maven speek: dependencies dependency groupIdjmock/groupId artifactIdjmock/artifactId version1.2.0/version /dependency dependency groupIdjmock/groupId artifactIdjmock/artifactId version2.0.0/version /dependency /dependencies jMock 2.x is designed to be used at the same time as jMock 1.x. My code uses both. So how can I define the deps? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon EU
I'm trying to sort out a way to go from OO to Wiki as I can't work anymore with OO. That's OmniOutliner not OpenOffice (which is a terrible piece of software). Which is terrible? OpenOffice or OmniOutliner? And if OpenOffice, why? - Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
On 25 Apr 07, at 9:00 AM 25 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 2:41 PM: On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Maven speek: dependencies dependency groupIdjmock/groupId artifactIdjmock/artifactId version1.2.0/version /dependency dependency groupIdjmock/groupId artifactIdjmock/artifactId version2.0.0/version /dependency /dependencies jMock 2.x is designed to be used at the same time as jMock 1.x. My code uses both. So how can I define the deps? First I'll ask why you are using both versions in one project and then I'll answer your question. Jason. - Jörg - 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: ApacheCon EU
On 25 Apr 07, at 9:11 AM 25 Apr 07, Steven Rowe wrote: I'm trying to sort out a way to go from OO to Wiki as I can't work anymore with OO. That's OmniOutliner not OpenOffice (which is a terrible piece of software). Which is terrible? OpenOffice or OmniOutliner? And if OpenOffice, why? OmniOutliner is _amazing_! Anything written by the OmniGroup is fabulous. I tried writing parts of a book with OpenOffice and I would rather pull out my own fingernails then use it again. On the MAC it's slow, has a terrible interface, generally hard to use and just butt ugly. I would use Word before I used OpenOffice now and coming from me that's quite a statement. Jason. - Steve - 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: Dep to same artifact in different versions
Jason van Zyl wrote on Wednesday, April 25, 2007 3:26 PM: On 25 Apr 07, at 9:00 AM 25 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 2:41 PM: On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Maven speek: dependencies dependency groupIdjmock/groupId artifactIdjmock/artifactId version1.2.0/version /dependency dependency groupIdjmock/groupId artifactIdjmock/artifactId version2.0.0/version /dependency /dependencies jMock 2.x is designed to be used at the same time as jMock 1.x. My code uses both. So how can I define the deps? First I'll ask why you are using both versions in one project and then I'll answer your question. Becasue I have 1000 of old unit tests with jMock 1.x, I am switching my project to JDK 5 and write my new unit tests with improved DSL and annotation support of jMock 2.x. No need at all to to convert the 1000 old tests (some might be converted over time). This is exaclty why jMock 1.x and jMock 2.x is designed to be used at the same time. - Jörg BTW: The same problem appears if your deps depend transitively on two development branches of the same artifact, that are classloader compatible (different class names) and might be used at the same time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
Doesn't the jmock2 contains the classes of jmock1 as well? On 4/25/07, Jörg Schaible [EMAIL PROTECTED] wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 3:26 PM: On 25 Apr 07, at 9:00 AM 25 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 2:41 PM: On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Maven speek: dependencies dependency groupIdjmock/groupId artifactIdjmock/artifactId version1.2.0/version /dependency dependency groupIdjmock/groupId artifactIdjmock/artifactId version2.0.0/version /dependency /dependencies jMock 2.x is designed to be used at the same time as jMock 1.x. My code uses both. So how can I define the deps? First I'll ask why you are using both versions in one project and then I'll answer your question. Becasue I have 1000 of old unit tests with jMock 1.x, I am switching my project to JDK 5 and write my new unit tests with improved DSL and annotation support of jMock 2.x. No need at all to to convert the 1000 old tests (some might be converted over time). This is exaclty why jMock 1.xand jMock 2.x is designed to be used at the same time. - Jörg BTW: The same problem appears if your deps depend transitively on two development branches of the same artifact, that are classloader compatible (different class names) and might be used at the same time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Model 3.0.2 for Maven 1.x released
We are pleased to announce the Maven Model 3.0.2 release!http://maven.apache.org/maven-1.x/plugins/file-activity/ In this new version, the pom v 3 can be read/write with xpp3, dom4j and stax. In maven 1.1 RC1 we now use the stax reader/writer which supports xml entities to reintroduce the compatibility with old maven 1.0.X projects. You can find the new web site in [1] and the model documentation [2] (which replaces the one actually in the maven 1 site [3]). Have fun! -The Maven team [1] http://maven.apache.org/maven-1.x/reference/maven-model/3.0.2/http://maven.apache.org/maven-1.x/plugins/file-activity/ [2] http://maven.apache.org/maven-1.x/reference/maven-model/3.0.2/maven.htmlhttp://maven.apache.org/maven-1.x/plugins/file-activity/ [3] http://maven.apache.org/maven-1.x/reference/project-descriptor.html
Re: [m2] Conflict resolvers
Hi Jason, Thanks for the reply. I was following the MNG-1577 debate and agree that this is certainly a step in the right direction. The dependency management solution is suitable for smaller projects with a manageable set of transitive dependencies, although it starts to grow unwieldy with larger projects and begins to resemble M1's flattened list of dependencies. To give an example of the number of components within our top-level projects: a typical project has 151 dependencies, 89 of which are internal, and the dependency tree goes up to 7 levels deep. We currently have 25 of these projects, each of which are on differing versions of our internal components. It's easy to see that managing a list of 150 dependency versions across 25 different dependency management sections soon becomes a maintenance nightmare. Ultimately we intend to use newest-wins conflict resolution in combination with ranges once MRELEASE-177 is fixed. This should resolve the problem of conflict resolution upgrading transitive dependencies to incompatible versions. Even in the case where ranges are not being used, I find nearest-wins conflict resolution so arbitrary when working on projects with a large dependency tree. We've spent hours digging through dependency trees after encountering runtime linking errors. I do like the notion of applying a chain of transformers to the fully parsed dependency graph, although I assume this would be targeted for 2.1? We've been using 2.0 since the early alphas and are now enjoying a degree of stability, so I'd rather not move to 2.1 until it becomes final. The MNG-612 patch preserves the current nearest-wins conflict resolution, but allows the implementation to be changed for those who require it. I would have thought this would be a good compromise for the 2.0.x branch until 2.1 supersedes it? Cheers, Mark On 25/04/07, Jason van Zyl [EMAIL PROTECTED] wrote: Not sure if you noticed the MNG-1577 debate, but much of the conflict resolution has been solved by the specification of the versions in depMan ruling out over anything. Now the cases where you are pulling in a transitive dependency that can come from two, or more, distinct subgraphs that you have not defined in your depMan is where some form of conflict resolution might come into play. I think for the most part people would want to be able to see this transitive graph and select the version, until such a time that we can say definitively that the latest version of something is compatible with everything else being used. I think we are quite a ways away from that people would probably end up locking down a version in depMan. But ultimately what is currently there must be replaced by a system that does not alter the graph while the graph is forming. By this I mean the entire graph must be resolved first and any subsequent transformation whether that be scope state changes, version alignment, and repository ordering must be done using standard graph transformation. We simply need a resolution specification and it has to be based on a graph being the fundamental unit of work. There is far too much transformation going on mid stream and it causes problems, and we lose critical information that would make deterministic choices hard if not impossible right now. It will be one of the things I will be bring up at ApacheCon and JavaOne. It is the source of greatest bewilderment to users, especially the behavior prior to MNG-1577. So I would be hesitant to apply any of these changes to trunk. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne
I'll be at J1 too On 4/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, We can certainly continue any discussions from ApacheCon at JavaOne and I have chatted with the folks at Terracotta and they would be happy to put us up for a couple days in one of their conference rooms where we can work and hold a BOF if we so choose. We can also have a conference room for a 2-3 days in succession so we have a place to continue discussions once things get started. So again we might want to put up a calendar and let people slot in their available times and I will schedule the rooms at TC. They are not that far from Moscone centre and we can easily get there quickly by cab, I can probably organize some transportation as well. Thanks to the folks at Terracotta as it's generally hard to get facilities setup where people can actually work. There's room for 10-15 people so folks should probably sign up soon, or let me know. I know for sure that myself, Eric Redmond, Kenney Westerhof, Andy Williams, John Casey, and Brett Porter will be present. If we select a date for a BOF then I can definitely schedule that. It would be a great opportunity for any users in the area to come out as it will probably be the highest concentration of core committers on record! :-) Just ping me if you're interested in attending something so I can make arrangements with Steve Harris at Terracotta. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne
Cool, John setup a calendar and if we all put available times there then I can propose some meeting times. With a little notice there is no problem getting space at the Terracotta offices. They have a big conference room with whiteboards we can use and they are fine with giving us the room for a couple days. So we can definitely do a BOF there and some working sessions. Thanks, Jason. On 25 Apr 07, at 12:14 PM 25 Apr 07, Carlos Sanchez wrote: I'll be at J1 too On 4/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, We can certainly continue any discussions from ApacheCon at JavaOne and I have chatted with the folks at Terracotta and they would be happy to put us up for a couple days in one of their conference rooms where we can work and hold a BOF if we so choose. We can also have a conference room for a 2-3 days in succession so we have a place to continue discussions once things get started. So again we might want to put up a calendar and let people slot in their available times and I will schedule the rooms at TC. They are not that far from Moscone centre and we can easily get there quickly by cab, I can probably organize some transportation as well. Thanks to the folks at Terracotta as it's generally hard to get facilities setup where people can actually work. There's room for 10-15 people so folks should probably sign up soon, or let me know. I know for sure that myself, Eric Redmond, Kenney Westerhof, Andy Williams, John Casey, and Brett Porter will be present. If we select a date for a BOF then I can definitely schedule that. It would be a great opportunity for any users in the area to come out as it will probably be the highest concentration of core committers on record! :-) Just ping me if you're interested in attending something so I can make arrangements with Steve Harris at Terracotta. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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: JavaOne
Well, I am available just about any time, so I shan't put my free times on the calendar, it will just take up space :) Andy On 25 Apr 2007, at 19:10, Jason van Zyl wrote: Cool, John setup a calendar and if we all put available times there then I can propose some meeting times. With a little notice there is no problem getting space at the Terracotta offices. They have a big conference room with whiteboards we can use and they are fine with giving us the room for a couple days. So we can definitely do a BOF there and some working sessions. Thanks, Jason. On 25 Apr 07, at 12:14 PM 25 Apr 07, Carlos Sanchez wrote: I'll be at J1 too On 4/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, We can certainly continue any discussions from ApacheCon at JavaOne and I have chatted with the folks at Terracotta and they would be happy to put us up for a couple days in one of their conference rooms where we can work and hold a BOF if we so choose. We can also have a conference room for a 2-3 days in succession so we have a place to continue discussions once things get started. So again we might want to put up a calendar and let people slot in their available times and I will schedule the rooms at TC. They are not that far from Moscone centre and we can easily get there quickly by cab, I can probably organize some transportation as well. Thanks to the folks at Terracotta as it's generally hard to get facilities setup where people can actually work. There's room for 10-15 people so folks should probably sign up soon, or let me know. I know for sure that myself, Eric Redmond, Kenney Westerhof, Andy Williams, John Casey, and Brett Porter will be present. If we select a date for a BOF then I can definitely schedule that. It would be a great opportunity for any users in the area to come out as it will probably be the highest concentration of core committers on record! :-) Just ping me if you're interested in attending something so I can make arrangements with Steve Harris at Terracotta. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
Re: ApacheCon EU
Hi Brett, I've got it arranged to get a co-worker of mine to go to your training, with the goal of hearing things from you instead of me ;) List of my things : - Give an overview of what's going on the Netherlands atm in relation to Maven2. - Discussion on the *current* state of things (not in depth, just general) - A lot of other thoughts coming from the first option - The Maven Plugin for Eclipse (!= the mojo). In short : I've written one myself and would like to move that back to MevenIDE. Mvgr, Martin Brett Porter wrote: Hi, I saw that Dennis, Jason, Kenney, Eric, Martin, Robert, and Arnaud B will all be at AC EU next week - is anyone else attending ApacheCon? I think it would be good to get some time in front of a white board to go through a couple of the big issues while we have the opportunity for face time and to hack some things together. It sounds like the same opportunity will present itself at JavaOne too. Of course, we can discuss some in real time with people on IRC and bring any output back to the list so everyone gets a chance to participate. What day/time would suit people? Maybe the following are appropriate for AC: - anything more we can do for releases (polish up the staging stuff, incorporate RAT, ...?) - plugin integration testing and unit testing - roadmap discussion / highlighting other issues Any other thoughts? Interest from the folks attending in anything in particular? - 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]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (40 issues) Subscriber: mavendevlist Key Summary 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-479 Invalid POI POM http://jira.codehaus.org/browse/MEV-479 MEV-478 jakarta-poi requires commons-lang as dependency http://jira.codehaus.org/browse/MEV-478 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 (32 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1502JPF - Java Plugin Framework http://jira.codehaus.org/browse/MAVENUPLOAD-1502 MAVENUPLOAD-1497Upload Unitils 1.0 rc 2 http://jira.codehaus.org/browse/MAVENUPLOAD-1497 MAVENUPLOAD-1493Uploading pyx4me 2.0.1 to The Central Repository http://jira.codehaus.org/browse/MAVENUPLOAD-1493 MAVENUPLOAD-1496Blogger API Client is an implementation of Blogger API for Java. Please upload! http://jira.codehaus.org/browse/MAVENUPLOAD-1496 MAVENUPLOAD-1488rxtx. upload : java serial and parallel I/O API http://jira.codehaus.org/browse/MAVENUPLOAD-1488 MAVENUPLOAD-1500Upload jMock 2.0.0 http://jira.codehaus.org/browse/MAVENUPLOAD-1500 MAVENUPLOAD-1501Upload UrlRewriteFilter 3.0.4 http://jira.codehaus.org/browse/MAVENUPLOAD-1501 MAVENUPLOAD-1499JEuclid 2.9.6 http://jira.codehaus.org/browse/MAVENUPLOAD-1499 MAVENUPLOAD-1476Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-1476 MAVENUPLOAD-1461Request to upload hamcrest api 1.0 bundle http://jira.codehaus.org/browse/MAVENUPLOAD-1461 MAVENUPLOAD-1462Request to upload hamcrest library 1.0 bundle http://jira.codehaus.org/browse/MAVENUPLOAD-1462 MAVENUPLOAD-1443Dozer Maven Upload Request http://jira.codehaus.org/browse/MAVENUPLOAD-1443 MAVENUPLOAD-1433Include guice in the central repository http://jira.codehaus.org/browse/MAVENUPLOAD-1433 MAVENUPLOAD-1405Eclipse SWT version 3.2.1 linux http://jira.codehaus.org/browse/MAVENUPLOAD-1405 MAVENUPLOAD-1399Upload xjavadoc 1.5 version to support JDK 1.5 annotations in xdoclet-maven-plugin http://jira.codehaus.org/browse/MAVENUPLOAD-1399 MAVENUPLOAD-1393xulfaces 0.9 Release for maven 2 http://jira.codehaus.org/browse/MAVENUPLOAD-1393 MAVENUPLOAD-1362Upload tapestry-flash to central repo http://jira.codehaus.org/browse/MAVENUPLOAD-1362 MAVENUPLOAD-1361Upload tapestry-prop 1.0.0 to Central repo http://jira.codehaus.org/browse/MAVENUPLOAD-1361 MAVENUPLOAD-1355Upload Core JSF Validator (commons validator integration) http://jira.codehaus.org/browse/MAVENUPLOAD-1355 MAVENUPLOAD-1346New IzPack jar's http://jira.codehaus.org/browse/MAVENUPLOAD-1346 MAVENUPLOAD-1307XML Bind Builder [Ant] http://jira.codehaus.org/browse/MAVENUPLOAD-1307 MAVENUPLOAD-1306XML Bind Generator http://jira.codehaus.org/browse/MAVENUPLOAD-1306 MAVENUPLOAD-1308XML Bind Builder [Maven] http://jira.codehaus.org/browse/MAVENUPLOAD-1308 MAVENUPLOAD-1305XML Bind Runtime http://jira.codehaus.org/browse/MAVENUPLOAD-1305 MAVENUPLOAD-1267Upload of novell jldap http://jira.codehaus.org/browse/MAVENUPLOAD-1267 MAVENUPLOAD-1149Upload jboss-seam-ui-1.0.1.jar http://jira.codehaus.org/browse/MAVENUPLOAD-1149 MAVENUPLOAD-1148Upload jboss-seam-debug-1.0.1.jar http://jira.codehaus.org/browse/MAVENUPLOAD-1148 MAVENUPLOAD-1147Upload jboss-seam-1.0.1.jar http://jira.codehaus.org/browse/MAVENUPLOAD-1147 MAVENUPLOAD-1130Rhino js-1.5R4.1 http://jira.codehaus.org/browse/MAVENUPLOAD-1130 MAVENUPLOAD-1128Rhino js-1.5R3 http://jira.codehaus.org/browse/MAVENUPLOAD-1128 MAVENUPLOAD-1129Rhino js-1.5R4-RC3 http://jira.codehaus.org/browse/MAVENUPLOAD-1129 MAVENUPLOAD-976Please upload SUN Java 1.2 rutime http://jira.codehaus.org/browse/MAVENUPLOAD-976 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
