With the Isolated Projects changes, what is the re...
# community-support
l
With the Isolated Projects changes, what is the recommended way to access arbitrary data from other projects. Specifically I am trying to access the Project.version and EclipseProject.name The first is needed for packaging metadata. The second is needed for me to generate run configs for eclipse considering it's not possible to debug gradle tasks in eclipse. I've tried looking into how the official Eclipse plugin does things. But it seems to just reach inside the other project like explicitly told not to do in the docs. It would also be useful to share other arbitrary data such as config values for custom plugin extensions. But figured i'd ask about vanilla gradle fields first.
p
Do you really need to access another project’s version? And the eclipse plugin is not yet migrated to IP, and you should use the BuildShip plugin instead when using Eclipse: https://github.com/eclipse-buildship/buildship
l
Yes, and the buildship plugin in the eclipse side of the gradle integration, so yes I am using it as its the only/default option when importing a project into eclipse.
s
I'm having a similar issue regarding sharing the root project's version with all projects in a multi-project setup. I'm solving that now by simply recalculating the version for each project in the same way I calculate it in the root project. As a positive side-effect, that would allow me to version individual subprojects separately from the root project going forward.
This is in the context of using github.com/jmongard/Git.SemVersioning.Gradle, BTW.
v
It depends on concrete situation. If you for example have a convention plugin you apply to all projects and the information can come from there, it can just register an extension from where you get the information. If you need to share information from one build script to the other, you could use a shared build service where one project stores the information in and the other can read it from. This could currently still work as parent projects are configured before child projects, but on the long run all projects should configure concurrently iirc. It also depends on when you need the information, if you only need it in the other project at execution time, the providing project could store it in a file and have an outgoing configuration providing that file and the consumer can then resolve that variant and read the information from the file. If you need the information at configuration time of the other project and only configuration time of the providing project can provide the value, that might be a problem.
👍 1
l
Sebastian, the version is a similar situation. We have our own git based versioning/changelog plugin So basically trying to sync versions for all sub-projects based on the main one. Eventually allowing each project to have its own version, but still reference the parent version. As for the concrete example of needing eclipsemodel.project.name, Building the launch configurations classpath requires the exact eclipse project name Version numbers and project name are needed at configuration time. The current concrete examples of arbitrary data is our run configurations where a convention plugin will apply them to each specific project, But I want a way to 'run datagen with all other projects that have data runs' I'll probably end up making a json file that only gets added in dev (non-ci) that spits out some form of marker for output locations and mod is per project. Or ideally, find a way to get the eclipse project name so I can build the launch group run config. The extra info could probably be used at runtime, so I can provide some metadata file. But would be nice for some arbitrary way to pass information between projects. Perhaps gradle needs some form of light-weight configuration phase that just allows gathering data to be stored in a global config build service. Which then can be used in the normal configuration phase of each sub-project individually. And ya i looked into build services, but with project isolation it seems that way is going to be dyeing off.