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

mlCreateTransform is creating resources in "test" instead of main "ml-modules" #507

Closed
s3-4v opened this issue Sep 30, 2019 · 1 comment
Closed
Assignees
Milestone

Comments

@s3-4v
Copy link

s3-4v commented Sep 30, 2019

Hi, in a Grove project running ml-gradle version 3.14, for one dev, mlCreateTransform is apparently creating the resources in an unexpected location:

$ ./gradlew mlCreateTransform -PtransformName=test-transform -PtransformType=sjs

> Task :mlCreateTransform
Creating new transform at ...\compas\marklogic\test\ml-modules\transforms\test-transform.sjs
Creating new transform metadata file at ...\compas\marklogic\test\ml-modules\transforms\metadata\test-transform.xml

I'm not able to reproduce this result -- the same command with the same project repo for me is creating the resources in the proper path.

I've requested the output of .gradlew -- version from the other developer so we can compare configurations.

Thanks.

@s3-4v s3-4v changed the title mlCreateTransform is creating resources in "test" instead of "ml-modules" mlCreateTransform is creating resources in "test" instead of main "ml-modules" Sep 30, 2019
@rjrudin
Copy link
Contributor

rjrudin commented Sep 30, 2019

mlCreateResource and mlCreateTransform both have to pick a module path from the list of module paths. They currently pick the last path to avoid any issues with writing the modules to an mlBundle-associated directory. But if you then have e.g. mlModulePaths=src/main/ml-modules,src/test/ml-modules - then they get written to the test directory, since that's the last path.

I'm now thinking though that when this change was made, it was due to mlModulePaths being modified to have a bundle path in it for the purposes of tweaking bundle code while running mlWatch. That's a much less important use case than supporting what should be a common use case of appending src/test/ml-modules to mlModulePaths.

So no need for any logging or gradle output - I'll modify these tasks to use the first module path. I think well over 80% of the time, that should be the appropriate location.

@rjrudin rjrudin added this to the 3.17.0 milestone Sep 30, 2019
@rjrudin rjrudin modified the milestones: 3.17.0, 3.16.3 Nov 13, 2019
@rjrudin rjrudin self-assigned this Nov 13, 2019
@rjrudin rjrudin closed this as completed Nov 13, 2019
hansenmc pushed a commit to hansenmc/ml-gradle that referenced this issue Dec 24, 2021

Verified

This commit was signed with the committer’s verified signature. The key has expired.
addaleax Anna Henningsen
… path
rjrudin pushed a commit that referenced this issue Aug 23, 2024

Verified

This commit was signed with the committer’s verified signature. The key has expired.
addaleax Anna Henningsen
Better invalid numeric property error handling
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