Hi Karl, Thanks again for the argument. For me it's still a valid question of how for example the license plugin would apply itself on its source structure to fix/update Java header before a release? (Of course, I understand the principle of linearizability to fix the circular issue).
Just in case, this is what I've been trying to apply this to: https://github.com/google/google-java-format/issues/69 The plugin should be able to apply the formatter to itself before any commit for example. Regards, Behrooz On Mon, Jul 18, 2016 at 9:59 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi, > > On 7/18/16 9:31 PM, Behrooz Nobakht wrote: > >> Hi, >> >> Thanks for the reply and I agree with the logical circular dependency >> argument. >> But I still believe that this is valid test/use case for a Maven plugin >> being developed. >> > > I don't agree with that...cause for those things it is best having IT's > based on maven-invoker-plugin....which will solves the problem here.. > > >> The profile idea 'self-test/run' works in this case for what I'm working >> on; >> but I think main reason is that logic here only applies to Java sources >> and >> the default is process-sources. In this, the plugin needs to run against >> itself >> before any release. >> > > The problem here is simply you need to do a mvn install before anything > else..without a preliminary install you won't get it working...cause during > the release process you need an installed version of your plugin..but this > must be a SNAPSHOT version which can't be used during a release cause you > will rely on an unstable non reproducible artifact (it does not matter if > its a plugin or a dependency)...You will create a tag from that state which > makes that permanent which is simply wrong! (Apart from that the release > plugin will prevent that already)... > > Nevertheless that profile does not really change a thing here... > > In it's consquence it's wrong...This kind of bootstrap can be handled by > using maven-invoker-plugin to write appropriate integration tests... > > Apart from that I don't see any change here if this would be > C++/Kotlin/Groovy or something else ? > > Kind regards > Karl Heinz > > > >> Regards, >> Behrooz >> >> >> On Mon, Jul 18, 2016 at 1:00 PM, Karl Heinz Marbaise <khmarba...@gmx.de> >> wrote: >> >> >>> Hi, >>> >>> trying to run your own plugin which you are developing within the same >>> project will not work cause that already sounds like a circle .. >>> >>> That's the reason to use invoker-plugin to have full fledged project >>> running as tests... >>> >>> A profile will not really help, cause you need to do a `mvn install` >>> first >>> and than run your project with something like `mvn -Pself-testing >>> verify` ? >>> Not a good idea? >>> >>> And finally this is not best practice... >>> >>> What you can do is to define a previous released version of your plugin >>> in >>> your pom ...That's what for example maven-invoker-plugin itself is >>> doing.. >>> ;-) >>> >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> On 7/18/16 9:43 AM, Behrooz Nobakht wrote: >>> >>> Hi, >>>> >>>> I am developing a Maven Plugin and trying to follow documentation[1] to >>>> use >>>> maven-invoker-plugin >>>> from the auto-generated profile 'run-its' to run an execution of the >>>> plugin >>>> under dev on itself. >>>> >>>> As an example, let's consider mojouas/license-maven-plugin. One of it's >>>> goals is 'update-file-header'. >>>> And, it actually has an integration-test executed by >>>> maven-invoker-plugin >>>> but it's on a sample project. >>>> What if I wanted to run the update-file-header on the >>>> license-maven-plugin >>>> itself? How? >>>> >>>> One straight way would be introduce another profile to configure the >>>> plugin >>>> to run on itself, but is this a >>>> good practice on Maven plugin development? >>>> >>>> Thanks, >>>> Behrooz >>>> >>>> >>>> >>>> [1]: http://maven.apache.org/plugins/maven-invoker-plugin/ >>>> [2]: >>>> >>>> >>>> https://github.com/mojohaus/license-maven-plugin/tree/master/src/it/update-file-header-test-mojo >>>> >>>> >>>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- -- Behrooz Nobakht
