You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Matthew Ouyang (JIRA)" <ji...@apache.org> on 2017/10/29 12:43:00 UTC

[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&focusedCommentId=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)