[jira] [Commented] (MNG-5588) Scope import in pluginManagement
[
https://issues.apache.org/jira/browse/MNG-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903250#comment-16903250
]
Matthew Ouyang commented on MNG-5588:
-
[~dimitrovchi] I would argue that both a new scope and MNG-5102 are unnecessary
for this ticket. If you're importing a pom then you import the whole thing,
not just the dependencyManagement portion. Maybe whatever part of the code
that parses the pom and sets up dependencyManagement can be augmented to set up
in pluginManagement as well.
> Scope import in pluginManagement
>
>
> Key: MNG-5588
> URL: https://issues.apache.org/jira/browse/MNG-5588
> Project: Maven
> Issue Type: Wish
> Components: Dependencies, FDPFC, POM
>Affects Versions: 3.1.1
>Reporter: Romain N
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> I can do this in dependencyManagement to define dependencies versions:
> {code}
>
> test
> test
> 1
>import
>pom
>
> {code}
> It could be great to can do the same things in pluginManagements to define
> version plugin and default behavior.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MCLEAN-79) Partial Clean + Configurable Selectors
[ https://issues.apache.org/jira/browse/MCLEAN-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16235015#comment-16235015 ] Matthew Ouyang commented on MCLEAN-79: -- Sometimes I forget to clean, and that causes headaches :) I admit I'm not using the latest plugin versions across the board, so I'll check out the other plugins when I can. > Partial Clean + Configurable Selectors > -- > > Key: MCLEAN-79 > URL: https://issues.apache.org/jira/browse/MCLEAN-79 > Project: Maven Clean Plugin > Issue Type: New Feature >Affects Versions: 3.0.0 >Reporter: Matthew Ouyang >Priority: Major > Labels: features > Attachments: clean-partial.patch > > > Partial cleanup would be useful in situations where source files are deleted > or changing between feature branches (which also can result in deleted source > files). This would eliminate the need to do a full clean. > Looking for feedback on provided patch. To enable this, Selectors need to be > configurable + some POC implementations (IdentitySelector, JavaSelector) have > between provided. The patch also includes a page that describes the new > feature in more detail, and Selectors have been placed in a separate package > (now that there is more than one implementation). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MCLEAN-79) Partial Clean + Configurable Selectors
[
https://issues.apache.org/jira/browse/MCLEAN-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223753#comment-16223753
]
Matthew Ouyang edited comment on MCLEAN-79 at 10/29/17 12:42 PM:
-
I commonly run into issues when I am switching branches during development.
Here are some situations I have experienced that my proposal hopes to address.
* My starting branch has a new Java class A.java that the branch I switch to
does not have. Timestamp-based checks won't detect A.java is now gone and
delete A.class automatically, and if I don't do a clean then my jar will
include A.class and I have experienced cryptic errors later in the pipeline.
* The situation above is also applicable for moving resources from source to
target although the consequences are minimal.
* (more obscure) I'm trying to make an SDK compatible with Java 7, and I need
to remove new Java 8 features from a class. If the class was previously
compiled in Java 8, it would be nice to recompile this class under Java 7 and
timestamp checks won't be sufficient for this either. Without a clean, I'll
eventually run into the "unsupported major.minor version."
It won't be possible to handle every situation (e.g. multiple classes defined
in a single source file), but my main objective with this is to make a better
efforts towards avoid a {{clean}}.
was (Author: mouyang):
I commonly run into issues when I am switching branches during development.
Here are some situations I am hoping to address.
* My starting branch has a new Java class A.java that the branch I switch to
does not have. Timestamp-based checks won't detect A.java is now gone and
delete A.class automatically, and if I don't do a clean then my jar will
include A.class and I have experienced cryptic errors later in the pipeline.
* The situation above is also applicable for moving resources from source to
target although the consequences are minimal.
* (more obscure) I'm trying to make an SDK compatible with Java 7, and I need
to remove new Java 8 features from a class. If the class was previously
compiled in Java 8, it would be nice to recompile this class under Java 7 and
timestamp checks won't be sufficient for this either. Without a clean, I'll
eventually run into the "unsupported major.minor version."
It won't be possible to handle every situation (e.g. multiple classes defined
in a single source file), but my main objective with this is to make a better
efforts towards avoid a {{clean}}.
> Partial Clean + Configurable Selectors
> --
>
> Key: MCLEAN-79
> URL: https://issues.apache.org/jira/browse/MCLEAN-79
> Project: Maven Clean Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Matthew Ouyang
> Labels: features
> Attachments: clean-partial.patch
>
>
> Partial cleanup would be useful in situations where source files are deleted
> or changing between feature branches (which also can result in deleted source
> files). This would eliminate the need to do a full clean.
> Looking for feedback on provided patch. To enable this, Selectors need to be
> configurable + some POC implementations (IdentitySelector, JavaSelector) have
> between provided. The patch also includes a page that describes the new
> feature in more detail, and Selectors have been placed in a separate package
> (now that there is more than one implementation).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCLEAN-79) Partial Clean + Configurable Selectors
[
https://issues.apache.org/jira/browse/MCLEAN-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223753#comment-16223753
]
Matthew Ouyang commented on MCLEAN-79:
--
I commonly run into issues when I am switching branches during development.
Here are some situations I am hoping to address.
* My starting branch has a new Java class A.java that the branch I switch to
does not have. Timestamp-based checks won't detect A.java is now gone and
delete A.class automatically, and if I don't do a clean then my jar will
include A.class and I have experienced cryptic errors later in the pipeline.
* The situation above is also applicable for moving resources from source to
target although the consequences are minimal.
* (more obscure) I'm trying to make an SDK compatible with Java 7, and I need
to remove new Java 8 features from a class. If the class was previously
compiled in Java 8, it would be nice to recompile this class under Java 7 and
timestamp checks won't be sufficient for this either. Without a clean, I'll
eventually run into the "unsupported major.minor version."
It won't be possible to handle every situation (e.g. multiple classes defined
in a single source file), but my main objective with this is to make a better
efforts towards avoid a {{clean}}.
> Partial Clean + Configurable Selectors
> --
>
> Key: MCLEAN-79
> URL: https://issues.apache.org/jira/browse/MCLEAN-79
> Project: Maven Clean Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Matthew Ouyang
> Labels: features
> Attachments: clean-partial.patch
>
>
> Partial cleanup would be useful in situations where source files are deleted
> or changing between feature branches (which also can result in deleted source
> files). This would eliminate the need to do a full clean.
> Looking for feedback on provided patch. To enable this, Selectors need to be
> configurable + some POC implementations (IdentitySelector, JavaSelector) have
> between provided. The patch also includes a page that describes the new
> feature in more detail, and Selectors have been placed in a separate package
> (now that there is more than one implementation).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCLEAN-79) Partial Clean + Configurable Selectors
[
https://issues.apache.org/jira/browse/MCLEAN-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223695#comment-16223695
]
Matthew Ouyang commented on MCLEAN-79:
--
I didn't realize clean is a separate lifecycle altogether so thank you for
pushing me to look into that altogether. I agree with you that we should be
running {{verify}} instead of {{clean install}}.
I understand your rationale for having individual plugins handle their own
cleanup. I was worried about code duplication (particularly compiler and
resources) and wanted to leverage the directory traversal code, but this seems
like a minor worry because it is pretty easy to code a directory traversal.
So what you are saying is that the compiler plugin would remove dangling class
files, the resources plugin would remove dangling resources, and any plugin
that takes part in the generate-sources phase will remove the sources it
generates that later become orphaned. Finally, clean is the standby in case
these plugins don't remove enough files. Correct? Please confirm and then I
will implement.
Lastly (this goes without saying) don't apply the patch. At least,, not yet.
> Partial Clean + Configurable Selectors
> --
>
> Key: MCLEAN-79
> URL: https://issues.apache.org/jira/browse/MCLEAN-79
> Project: Maven Clean Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Matthew Ouyang
> Labels: features
> Attachments: clean-partial.patch
>
>
> Partial cleanup would be useful in situations where source files are deleted
> or changing between feature branches (which also can result in deleted source
> files). This would eliminate the need to do a full clean.
> Looking for feedback on provided patch. To enable this, Selectors need to be
> configurable + some POC implementations (IdentitySelector, JavaSelector) have
> between provided. The patch also includes a page that describes the new
> feature in more detail, and Selectors have been placed in a separate package
> (now that there is more than one implementation).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MCLEAN-79) Partial Clean + Configurable Selectors
Matthew Ouyang created MCLEAN-79: Summary: Partial Clean + Configurable Selectors Key: MCLEAN-79 URL: https://issues.apache.org/jira/browse/MCLEAN-79 Project: Maven Clean Plugin Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Matthew Ouyang Attachments: clean-partial.patch Partial cleanup would be useful in situations where source files are deleted or changing between feature branches (which also can result in deleted source files). This would eliminate the need to do a full clean. Looking for feedback on provided patch. To enable this, Selectors need to be configurable + some POC implementations (IdentitySelector, JavaSelector) have between provided. The patch also includes a page that describes the new feature in more detail, and Selectors have been placed in a separate package (now that there is more than one implementation). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCLEAN-78) Ability to retry longer if clean fails
[ https://issues.apache.org/jira/browse/MCLEAN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214140#comment-16214140 ] Matthew Ouyang commented on MCLEAN-78: -- [~cowwoc] The ability to configure unlimited retries might be a better solution fit for your situation. What do you think? I also wonder what the project team thinks of this proposal. > Ability to retry longer if clean fails > -- > > Key: MCLEAN-78 > URL: https://issues.apache.org/jira/browse/MCLEAN-78 > Project: Maven Clean Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 > Environment: Windows 10, 64-bit, build 10.0.14393 >Reporter: Gili > > Following up on MCLEAN-45, I am running into a problem where a build fails to > clean 100% of the time. The existing retry mechanism sleeps roughly 1 second, > which makes it impossible to investigate what is actually holding the lock. I > already went through the obvious culprits by disabling Windows Indexing and > anti-virus, to no avail. I can reproduce the problem on two separate machines > as well. I am afraid that Maven itself might be holding the lock. > I order to aid troubleshooting of this scenario, can you please add or > enhance the existing configuration options so that the clean plugin can retry > longer (e.g. up to 30 seconds)? > Worse-case scenario, the lock will eventually get released and my build will > work. Best-case scenario, the lock won't get released but I will finally have > enough time to run SysInternals ProcessMonitor to figure out who is holding > the lock. When I try doing this after the JVM shuts down, I don't find anyone > holding the lock so I strongly suspect the JVM itself is at fault. > Proposal: let users specify a max retry time and generate the intermediate > sleep intervals on their behalf. I would happily use retry intervals of up to > a minute if it meant that my automated builds would be more stable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
