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

connector type archive generated files need excluding from git #2324

Closed
planetf1 opened this issue Dec 31, 2019 · 4 comments
Closed

connector type archive generated files need excluding from git #2324

planetf1 opened this issue Dec 31, 2019 · 4 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@planetf1
Copy link
Member

#2319 introduced the execution of a connector types archive builder within the build process.

After running a build the following new files were found in tracked git directories:

	DataStoreConnectorTypes.json
	DataStoreConnectorsGUIDMap.json
	open-metadata-resources/open-metadata-archives/open-connector-archives/DataStoreConnectorTypes.json
	open-metadata-resources/open-metadata-archives/open-connector-archives/DataStoreConnectorsGUIDMap.json

These should be removed from git tracking - either by exclusion, or by writing them into a target directory instead of source location.

@planetf1 planetf1 added the bug Something isn't working label Dec 31, 2019
@planetf1 planetf1 added this to the 2019.12 (1.3) milestone Dec 31, 2019
@planetf1 planetf1 self-assigned this Dec 31, 2019
@planetf1 planetf1 changed the title generated files need excluding from git connector type archive generated files need excluding from git Dec 31, 2019
@planetf1
Copy link
Member Author

Note that in the above I have the files in two locations.
I ran the build once from the root, but also ran it directly from 'open-connector-archives' - so it looks like it may be writing files into the current working directory.

In the build process (from within maven) we should ensure this is always written to a consistent location.

@planetf1
Copy link
Member Author

We can use

<workingDirectory>/tmp</workingDirectory>

to specify the cwd when executing the java tool. I am thinking ${project.build.directory} is most appropriate - it would be the 'target' directory for this module.

Currently this archive doesn't appear to be used anywhere -- couldn't find in the assemblies. if/when it does we may need to revisit the appropriate location - (as well as the lifecycle phase the task is bound to)

planetf1 added a commit to planetf1/egeria that referenced this issue Dec 31, 2019
… target dir

Signed-off-by: Nigel Jones <nigel.l.jones+git@gmail.com>
mandy-chessell added a commit that referenced this issue Jan 1, 2020
#2324 correct connector archive type build proc to use consistent tar…
@mandy-chessell
Copy link
Contributor

Where is this utility is run by the build? I do not see the files appear in my build tree unless I run the utility directly. I would like to run it as part of the build - just not sure of the best way to do it.

Once we are running it as part of the build (and the other archive utilities) then can add resulting archive files to the assemblies - and then use them in the labs :)

@planetf1
Copy link
Member Author

planetf1 commented Jan 2, 2020

The utility was being run in open-metadata-resources/open-metadata-archives/open-connector-archives .. initially with maven exec.. now with antrun. However I don't think the results of the build are being used yet - as you say one requirement is that they are easily available to the notebook environment.

We start to get into #2215 here - I think we need to work through that in more detail -and of course ideally the tutorial environment should use the assemblies for all the egeria assets, that way we prove they are correct.

This particular issue is resolved by #2325 so will close.

I did note that in #2329 entries were added to gitignore, but IMO my fix #2325 was a better option - we should aim to create files outside the core source tree - it's confusing, and in this case was kinda masking another issue, which was that the files were not always created in the same place depending on the users cwd, #2325 fixed that making the gitignore entries superfluous (and arguably having more than we need in there is in itself confusing ...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants