Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The manipulationWriteChanged parameter and expected behavior #1012

Open
mborra opened this issue Sep 3, 2024 · 8 comments
Open

The manipulationWriteChanged parameter and expected behavior #1012

mborra opened this issue Sep 3, 2024 · 8 comments

Comments

@mborra
Copy link

mborra commented Sep 3, 2024

Hi to all, I have tried the new parameters manipulationWriteChanged but unfortunately it doesn't works as I expected, with this arguments the PME extension (extensions.xml) reports the correct actions in the logs, but the artifacts end with the postfix -SNAPSHOT:

clean install -DversionSuffix= -DmanipulationWriteChanged=false

If I remove the manipulationWriteChanged parameter then the POMs are rewritten and everything works, but it's not what I expected reading the documentation, I expected it to work in-memory.

Many thanks

@rnc
Copy link
Contributor

rnc commented Sep 18, 2024

Apologies I missed the notification of this issue.

Can you reproduce the problem if you install to lib/ext or use the CLI?
What version of PME is being shown to be used?
Can you provide logging output e.g. mvn validate -DversionSuffix= -DmanipulationWriteChanged=false ?

@mborra
Copy link
Author

mborra commented Sep 18, 2024

Hi, don't worry :)

I use the latest version 4.16,
Same behavior using it as lib/ext.
The rest will take me some time, I have to prepare a POC.

@rnc
Copy link
Contributor

rnc commented Sep 19, 2024

Ok I think I understand what you mean now. The problem is, PME was really only ever designed to modify the POMs and write them back out. The request to modify in memory, while feasible, isn't that helpful in its current format - this is because, as you can see, the results of the modification are not passed to other executions which are effectively independent. It might be possible to do something around the eventspy and update the model although avoiding corruption of the DAG is not straightforward.

@mborra
Copy link
Author

mborra commented Sep 23, 2024

Ok, I misunderstood the documentation, too bad, it was very useful to me.

@mborra
Copy link
Author

mborra commented Jan 17, 2025

Compromise... before applying changes create a backup of the poms, also implement a rollback goal, like the versions plugin does? Minimum effort, maximum yield :)

@rnc
Copy link
Contributor

rnc commented Jan 19, 2025

@mborra Having a flag to create backups of the poms (defaulted to off) would be acceptable I think. I am not convinced about needed any form of rollback. Would you be willing to contribute that feature?

@mborra
Copy link
Author

mborra commented Jan 21, 2025

The rollback would be just to avoid having to revert with git. I don't have a lot of time but it would be interesting to implement it.

@rnc
Copy link
Contributor

rnc commented Jan 22, 2025

I don't think the rollback is required really? Given a simple git reset --hard would solve the problem I don't see that its worth the effort. Further as their is no 'goals' per se to call (as this isn't a plugin) where that could be 'plugged in' is another question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants