creating a NOOP install-method

[k9ert]

I'm installing oracle-java via an own custom deb-package. This is nearly impossible with the current state of this cookbook. I could create a sophisticated new install-method however it might be more practical also for other usecases to create a no-operation install_method which simply would does nothing and deal with the installation method in some other way.

Would you accept such a pull-request? Anything you want me to consider for something like this?

[damacus]

might it be easier to to use the apt installer to deal with your custom apt package?

[k9ert]

The apt-installer is stuck currently
https://github.com/agileorbit-cookbooks/java/pull/179

... and i'm not sure whether it will help me and works as expected. I'm happy to use it as soon as it is there and is usable for me.
However: The java-cookbook is a very central piece and it's used in a lot of other cookbooks, e.g. maven/jenkins and others.

As such, i would expect it to be as flexible as possible which includes the possibility to just move out of the way if needed.

[erichelgeson]

Trying to understand what the nop would do in this case? Do you still want to use the alternatives and environment setting parts of this recipe? If so could you just call them directly, eg: java::set_attributes_from_version and java::set_java_home ? What I'm reading is you want to use the java cookbook but don't want it to do anything.

The Jenkins cookbook explicitly does not depend on this cookbook and is up to the user to make the decision on how Java should be installed (could be via this cookbook, or just package 'openjdk'). The mvn cookbook could follow that paradigm as well (maven and Jenkins are both java apps, and both are utilities intended to be used in wrapper cookbooks to function).

Honestly I may be missing what your saying too, help me understand.

[k9ert]

The jenkins-cookbook indeed does not need to use the java-cookbook. However the maven-cookbook uses that in the wrong way and probably we don't know which other cookbooks do it the wrong way, too.

I agree that the issue should be fixed THERE in the first place, but it would be really helpful if this cookbook can somehow contribute to a workaround in the meantime which is less complex than:

1. forking
2. implementing the nop-recipe
3. install a berkshelf-api in front of my chefserver
4. berks install my version of the community-cookbook into my chefserver with a weird versionnumber (1.24.100 because 1.24.0-companyName is not possible)
5. using that version in my wrapper-cookbooks

If you would accept that PR (which i need to improve before), then i can at least get rid of 1-4 until the maven-cookbook fixed it part of the story.

[erichelgeson]

I think I understand you're point now (let me reiterate)

• Other cookbooks you depend on depend on this cookbook
• You are already managing java in your own way
• Give you a node attribute to skip everything

That does make sense. Can you also open an issue with the maven recipe (referencing this issue) I opened an issue on the maven cookbook. I'll discuss this with the team and get back to you.

Thanks for helping me understand your use case.

[k9ert]

Thank you very much, especially for the issue-creation at maven. I'm happy to recreate the PR again (which i screwed up in its first version because of chef-newbie), just let me know.

[erichelgeson]

@k9ert Talking with the team and a few others we do not think the NOOP way is the to go. I've documented recommendations for depending on this recipe for other community cookbook maintainers and would be happy to create pull requests on other cookbooks if there are more out there.

[k9ert]

The issue at the maven-cookbook, although almost one month old, has not yet even qualified:
sous-chefs/maven#41

I think this makes clear, where the pain is. I know that i'm not a first-level-customer but just a kind of-second-level customer but it would be quite helpful if other cookbooks are not that responsive than you are (thanks for your responsiveness), to have that noop-cookbook.

Is there a particular reason you want to avoid to implement it?

[erichelgeson]

The reason is that this cookbooks purpose is to install java and configure it for you, making it so it does nothing is counter to its purpose.

The maven cookbook is just a few attributes fed to an ark resource and a template, may be simpler for you to fork that and maintain than this cookbook.

Since maven is under opscode-cookbooks I'll try to attend the next office hours to get it merged in.

Also you are a first-level-customer, anyone who uses this cookbook is!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.