You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My use case is that I have a significant number of jars to weave the same aspects into, using the same classpath, but would like to retain the same distinct jars as output.
At present the compile time weave processing is called per-jar, which means that the set up effort is repeated for each case.
The output options at the moment mean that if provided multiple jars on input either we end up with a single jar or directory containing all consolidated classes. In particular this means that any distinct resources which might be provided on a per-jar basis are lost/overwritten (the existing processing provides a warning of duplicate resource in these cases).
The text was updated successfully, but these errors were encountered:
@kriegaex thanks for the response - if I were to explore an implementation would it be acceptable for the project or is it deemed not required or should be solved in a different manner?
I do not want to prematurely judge in either direction. While I am not going to promise to accept such a contribution, I certainly have no intention to reject it right away either. In the end, it will depend on what the code looks like, its impact on the existing code, test coverage, maintainability etc.
Note to myself: #60 is loosely related, because it also touches upon the question what is written to disk under which circumstances. IMO, that would be a more interesting feature, but can be implemented independently of this one here.
My use case is that I have a significant number of jars to weave the same aspects into, using the same classpath, but would like to retain the same distinct jars as output.
At present the compile time weave processing is called per-jar, which means that the set up effort is repeated for each case.
The output options at the moment mean that if provided multiple jars on input either we end up with a single jar or directory containing all consolidated classes. In particular this means that any distinct resources which might be provided on a per-jar basis are lost/overwritten (the existing processing provides a warning of duplicate resource in these cases).
The text was updated successfully, but these errors were encountered: