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

Reply via email to