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

Composite builds support for nested jars #992

Open
wants to merge 2 commits into
base: exp/1.5
Choose a base branch
from

Conversation

ishland
Copy link

@ishland ishland commented Nov 26, 2023

Resolves #975

This delays dependency resolution for nested jars until it is actually needed because dependencies substituted from included builds doesn't actually resolve during configuration phase.

This also adds nestedConfigurations for RemapJar, allowing custom configurations to be used for inclusion.
Note that this still retains the behavior of not adding transitive dependencies as nested jars.

Copy link
Member

@modmuss50 modmuss50 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont fully understand the problem tbh, this doesnt seem like the correct solution at all to me. A Configuration is a FileCollection so you should be able to do .from() on it getNestedJars().

An intergration test is needed for this as well, it might help me understand what the problem is.

Comment on lines +83 to 85
@Deprecated
@InputFiles
public abstract ConfigurableFileCollection getNestedJars();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot deprecate this, as its used for adding files that arent part of a Configuration

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding to this collection directly doesn't add any metadata even if the file isn't actually a mod jar. Files can also be added directly to Configurations. So it doesn't really make sense to me to actually keep this.

Comment on lines +128 to +138
@InputFiles
public FileCollection getNestedDependenciesResolved() { // for task up-to-date checking
final ConfigurableFileCollection files = getProject().files();

if (getAddNestedDependencies().get()) {
getNestedConfigurations().get().forEach(files::from);
files.from(getNestedJars());
}

return files;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this any different from putting the Configuration in the existing ConfigurableFileCollection

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding configuration directly to the existing ConfigurableFileCollection causes duplicates. That collection also doesn't take care of metadata.

Based on `simple` test
@modmuss50
Copy link
Member

Thanks for adding a test, im still not super happy with this fix, but dont have a better suggestion off the top of my head. Ill have to sit down and take a better look into this.

@lukebemish
Copy link
Contributor

This is likely superseded by #1080, which is a more idiomatic approach - storing Configuration as a task input as this PR does makes the task incompatible with configuration cache, so that would have to be changed later anyway, and my PR switches everything to use the normal configuration resolution system. I will, however, add the tests from this PR for composite builds into my PR, to ensure that using include with those continues to work.

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

Successfully merging this pull request may close these issues.

3 participants