* 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 >>>>>>>> --------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >