For everything that is not claimed in a couple days can move to 3.2.x and that gets it out of the 3.2.0 bucket, and from there you can percolate up to 4.x.
On Jan 7, 2014, at 11:47 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > * http://jira.codehaus.org/browse/MNG-656 lazily resolve extensions > > Not sure that this is a reasonable ask. Moving to 4.x anyway > > * http://jira.codehaus.org/browse/MNG-4508 No way to avoid adding > artifactId to site urls > > I think this is a 4.x candidate... objections? > > * http://jira.codehaus.org/browse/MNG-5205 Memory leak in > StringSearchModelInterpolator > > ACTION: krosenv to provide status update > > * http://jira.codehaus.org/browse/MNG-1569 Make build process info > read-only to mojos, and provide mechanism for explicit out-params for mojos > to declare > > This seems like 4.x scope. Objections? > > * http://jira.codehaus.org/browse/MNG-1867 deprecate system scope, analyse > other use cases > > I vote move to 4.x > > > On 7 January 2014 16:39, Stephen Connolly > <stephen.alan.conno...@gmail.com>wrote: > >> * http://jira.codehaus.org/browse/MNG-5185 Improve "missing dependency" >> error message when _maven.repositories/_remote.repositories contains other >> repository ids than requested >> >> The attached patch does not address the real issue, namely being able >> to define specific repo id's as offline. I would be happy to take a stab at >> the real issue, but likely do not have the time. If nobody else has the >> time, we should move this to 3.2.x as it could be a patch level enhancement >> to the maven CLI options >> >> * http://jira.codehaus.org/browse/MNG-5366 [Regression] resolveAlways >> does not force dependency resolution in Maven 3.0.4 >> >> Seems legit >> >> ACTION: rfscholte to update status as from comments seems to have a >> handle on this one >> >> * http://jira.codehaus.org/browse/MNG-5494 Add a license file that >> corresponds to each GAV in the distribution >> >> I think jvzyl has this one under control. Can be pushed back if >> necessary as what we have currently works, if somewhat sub-optimal >> >> * http://jira.codehaus.org/browse/MNG-5265 enforce repository url >> verification for passing authz >> >> ACTION: olamy to provide status update, unclear from comment if 3.0.5 >> prints a warning (in which case I vote we close this issue) or if the >> intention was to add printing a warning to 3.0.5 >> >> * http://jira.codehaus.org/browse/MNG-3526 Small change to artifact >> version parsing. >> >> I have committed this issue >> >> >> On 7 January 2014 16:02, Stephen Connolly <stephen.alan.conno...@gmail.com >>> wrote: >> >>> * http://jira.codehaus.org/browse/MNG-5378 Use m-s-u in core >>> >>> ACTION: krosenv to provide status update >>> >>> * http://jira.codehaus.org/browse/MNG-5353 Ignore pre-releases in >>> exclusive upper bound [lw,up) >>> >>> ACTION: jvzyl will we be upping Aether to M4, in which case that will >>> expose an alternative version range syntax that resolves this issue... OTOH >>> that new syntax may cause issues for existing pom readers... in which case >>> this becomes a push back to 4.x >>> >>> * http://jira.codehaus.org/browse/MNG-5356 Make encrypt/decrypt logic >>> pluggable >>> >>> Seems like something that could be in scope. Any takers? >>> >>> * http://jira.codehaus.org/browse/MNG-5389 AbstractMavenLifecycleParticipant >>> need a afterSessionEnd >>> >>> ACTION: jvzyl to provide status update >>> >>> * http://jira.codehaus.org/browse/MNG-3092 Version ranges with >>> non-snapshot bounds can contain snapshot versions >>> >>> Do we have a decision as to what we will do with this one? It is one >>> of the longest discussions we have... >>> >>> >>> On 7 January 2014 15:55, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>> >>>> * http://jira.codehaus.org/browse/MNG-3695 Allow dependencies' scopes >>>> to be managed without explicit versions >>>> >>>> This does not affect the pom schema, but potentially affects other >>>> POM parsers. My instinct is that this is for 4.x not 3.2 >>>> >>>> * http://jira.codehaus.org/browse/MNG-3321 Skip plugin and/or execution >>>> >>>> After reading more closely, this seems to be changing the POM >>>> schema, at least with the current patch, move to 4.x? >>>> >>>> * http://jira.codehaus.org/browse/MNG-3124 Inherit mailing lists from >>>> parent POM >>>> >>>> Sounds like an issue building the internal model. Additionally this >>>> would not be a change that affects other consumers and their processing of >>>> dependencies, so this looks like a valid candidate to me. >>>> >>>> * http://jira.codehaus.org/browse/MNG-2807 ciManagement from parent is >>>> not merging with children >>>> >>>> Same as MNG-3124. Both issues are related it would seem >>>> >>>> * http://jira.codehaus.org/browse/MNG-3825 Dependencies with classifier >>>> should not always require a version. >>>> >>>> Same as MNG-3695 >>>> >>>> * http://jira.codehaus.org/browse/MNG-4173 Remove automatic version >>>> resolution for POM plugins >>>> >>>> This is somewhat reasonable, but we have already kicked this can >>>> down the road and it may hinder adoption. I would be happy to kick this one >>>> to 4.x on the basis that most existing poms were written with the >>>> assumption that you could avoid specifying the plugin version... and we >>>> even omit the plugin version in the asf parent pom for some stuff... >>>> >>>> >>>> On 7 January 2014 15:45, Stephen Connolly < >>>> stephen.alan.conno...@gmail.com> wrote: >>>> >>>>> * http://jira.codehaus.org/browse/MNG-2478 add filtered resource >>>>> directories to super POM >>>>> >>>>> Moved to 4.x bucket as requires pom model change >>>>> >>>>> * http://jira.codehaus.org/browse/MNG-426 create "maxmem" setting for >>>>> all plugins to refer to >>>>> >>>>> I think this is now out of scope for core... but I would be >>>>> interested in what others think >>>>> >>>>> * http://jira.codehaus.org/browse/MNG-683 Lifecycle mappings should >>>>> specify phase bindings in terms of general functionality type >>>>> >>>>> This issue seems DOA at present... do we want to push it out again? >>>>> >>>>> * http://jira.codehaus.org/browse/MNG-841 Support customization of >>>>> default excludes >>>>> >>>>> The issue as currently written seems to imply a pom format >>>>> change... OTOH this could be handled by a standard property name. Probably >>>>> more an issue for plugins that slurp directories or for the plexus utils >>>>> that do this. >>>>> >>>>> * http://jira.codehaus.org/browse/MNG-193 symmetry for outputs of a >>>>> plugin >>>>> >>>>> Sounds like this is a Move to 4.x issue >>>>> >>>>> >>>>> On 7 January 2014 15:39, Stephen Connolly < >>>>> stephen.alan.conno...@gmail.com> wrote: >>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-2381 Improved control over the >>>>>> repositories in the POM >>>>>> >>>>>> Unsure what the ask is here >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-4506 Split site deployment URLs >>>>>> into release vs. snapshot, just like artifacts >>>>>> >>>>>> Moved to 4.x bucket as requires pom model change >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-3474 Add parameter --internet >>>>>> to test Internet access with and without using proxy defined in >>>>>> settings.xml >>>>>> >>>>>> Any takers... looks like a nice small feature to add >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-3879 Dependency map and >>>>>> documentation >>>>>> >>>>>> Moved to 4.x bucket as requires a pom model change >>>>>> >>>>>> ACTION: bmargulies - split the issue and rename existing issue so >>>>>> that the pom change is the title >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-4171 The XML resulting from a >>>>>> property of java.util.Properties is a lot more clumsy than that for Map >>>>>> >>>>>> Unsure what the ask is here... seems like it's really a plexus >>>>>> compatibility layer issue >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-4622 Throw Validation Error if >>>>>> pom contains a dependency with two different versions. >>>>>> >>>>>> I think we risk breaking too much with this one, we already emit >>>>>> the warning, and my view is that we should consider this as a POM >>>>>> specification change... it was poor specification in 4.0.0 that lead to >>>>>> permitting duplicate versions of the same dependency... OTOH for >>>>>> dependencies which are resources, there may be legitimate reasons for two >>>>>> versions of the same dependency... e.g. two versions of jquery webjars to >>>>>> be included in a webapp >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-2893 Update the >>>>>> DefaultPluginManager to not use a project depMan for controlling it's >>>>>> transitive dependencies >>>>>> >>>>>> Seems like a legitimate bug we should consider? >>>>>> >>>>>> * http://jira.codehaus.org/browse/MNG-2916 Default message and >>>>>> profile help messages >>>>>> >>>>>> Moved to 4.x bucket as requires pom model change >>>>>> >>>>>> >>>>>> On 7 January 2014 15:25, Stephen Connolly < >>>>>> stephen.alan.conno...@gmail.com> wrote: >>>>>> >>>>>>> OK we are now at 38 open issues.... anyone else feel like scrubbing >>>>>>> some more? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7 January 2014 15:25, Stephen Connolly < >>>>>>> stephen.alan.conno...@gmail.com> wrote: >>>>>>> >>>>>>>> Done >>>>>>>> >>>>>>>> >>>>>>>> On 7 January 2014 14:43, Jason van Zyl <ja...@tesla.io> wrote: >>>>>>>> >>>>>>>>> Seems reasonable. Go for it. >>>>>>>>> >>>>>>>>> On Jan 7, 2014, at 7:43 AM, Stephen Connolly < >>>>>>>>> stephen.alan.conno...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> AFAIU this is the current list of bugs: >>>>>>>>>> >>>>>>>>> http://jira.codehaus.org/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%20%223.2%22%20AND%20(status%20%3D%20Open%20OR%20status%20%3D%20%22In%20Progress%22%20or%20status%3DReopened)%20ORDER%20BY%20priority%20DESC >>>>>>>>>> >>>>>>>>>> I propose that the following issues all require a change to the >>>>>>>>> model >>>>>>>>>> version, and thus should be pushed back to 4.0.0 (or later) >>>>>>>>>> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-1977 Global dependency >>>>>>>>>> exclusions<http://jira.codehaus.org/browse/MNG-1977> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-2297 Change the POM to use >>>>>>>>>> attributes<http://jira.codehaus.org/browse/MNG-3397> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-5102 Mixin POM >>>>>>>>>> fragments<http://jira.codehaus.org/browse/MNG-5102> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-2199 Version ranges not >>>>>>>>> supported for >>>>>>>>>> parent artifacts <http://jira.codehaus.org/browse/MNG-2199> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-2216 Add default encodings >>>>>>>>> section to >>>>>>>>>> POM <http://jira.codehaus.org/browse/MNG-2216> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-3826 Add profile activation >>>>>>>>> when >>>>>>>>>> project version matches a regex < >>>>>>>>> http://jira.codehaus.org/browse/MNG-3826> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-2316 Add info to the poms for >>>>>>>>>> dependencies that implement an API or provide other dependencies >>>>>>>>>> http://jira.codehaus.org/browse/MNG-3326 Profile Deactivation >>>>>>>>> Configuration >>>>>>>>>> http://jira.codehaus.org/browse/MNG-2557 Various enhancements to >>>>>>>>> profiles >>>>>>>>>> http://jira.codehaus.org/browse/MNG-2598 Profile element in POM >>>>>>>>> should >>>>>>>>>> support overriding project.build.directory (WONTFIX candidate?) >>>>>>>>>> http://jira.codehaus.org/browse/MNG-3726 Extend POM model to >>>>>>>>> support >>>>>>>>>> declaration of IRC channels >>>>>>>>>> >>>>>>>>>> The following issues require that the deployed pom be different >>>>>>>>> from the >>>>>>>>>> on-disk pom, i.e. the same problem we had with 2.1.0 and 2.2.0... >>>>>>>>> again I >>>>>>>>>> think these should be pushed back to 4.0.0 (or later) >>>>>>>>>> >>>>>>>>>> http://jira.codehaus.org/browse/MNG-624 Automatic parent >>>>>>>>>> versioning<http://jira.codehaus.org/browse/MNG-624> >>>>>>>>>> >>>>>>>>>> I would propose that we move these issues into a 4.0 bucket... >>>>>>>>> that will >>>>>>>>>> bring us down to 31 issues open for 3.2.0 >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jason >>>>>>>>> >>>>>>>>> ---------------------------------------------------------- >>>>>>>>> Jason van Zyl >>>>>>>>> Founder, Apache Maven >>>>>>>>> http://twitter.com/jvanzyl >>>>>>>>> --------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
