[MNGSITE-443] Add setFile to Mojo Cookbook (website)

[jira-importer]

Casper Roubos opened MNGSITE-443 and commented

Is it possible to add in the 'my first mojo', that you need to register the output-directory in the artifact with project.getArtifact().setFile(..).

We are using a Jenkins muti-branch pipeline, and we found out that if you not build to install (e.q. process-test-classes) that the build will give an error because the dependency resolution can't find the artifact in the repo (because the first time it is not deployed yet).

 

Hope that this addition will also others.

---

No further details from MNGSITE-443

[jira-importer]

Amy(Zhongyang) Deng commented

Hi, I'm new to this and interested to help. Just to make sure, this task is to update documentation instead of making code changes?

For "Mojo Cookbook (website)" are you referring to https://docs.mojolicious.org/Mojolicious/Guides/Cookbook ?

[jira-importer]

Casper Roubos commented

Hi,

Yes, this issue is in regard to the documentation on the website, in particular the developers site on www.maven.org

[jira-importer]

Matthias Bünger commented

For "Mojo Cookbook (website)" are you referring to https://docs.mojolicious.org/Mojolicious/Guides/Cookbook ?

The "yes" in Casper's answer is a bit misleading. It's related to the question about updating the documentation (I will have a look at this in near future), but if Mojolicious.org is the correct web page. The answer to this is clearly "no".

Mojolicious is a fresh take on Perl web development, based on years of experience developing the Catalyst framework, and utilizing the latest web standards and technologies

[jira-importer]

Matthias Bünger commented

Having an additional look at the documentation, there is a section about Reading and Writing Text Files.

However, I doubt that what you describe has nothing to do with it.

we found out that if you not build to install (e.q. process-test-classes) that the build will give an error because the dependency resolution can't find the artifact in the repo (because the first time it is not deployed yet).

This sounds like a misunderstanding on your site. As long as a plugin (or any other project you build) is not installed/deployed it's not considered "released" / not visible for other projects. So it's not in the local/remote repository where the dependecy resolution would find it.

Could you give me more information about your setup and what are you are trying to do?

[jira-importer]

Casper Roubos commented

Hi,

Thanks for your patience. It seems that some of your previous emails did not get in through the email server.

I see that I did not correctly use the proper terms.

You are right: the item should not have been visible since it has not installed of deployed in any repository. In mine case I build a plugin that uses the output in the package phase of a previously packaged module in the same build, so in mine description I meant 'in the reactor' .

 

Hope this clarification helps.

 

[jira-importer]

Matthias Bünger commented

Sorry for late response, I'm quite busy at the moment.

For my further understanding:

You have a project with (at least) two subprojects, where the first (a library?) of them is a dependency of the second (the plugin) - correct? What do you mean with "output"? Do you mean the built artifact, e.g. the JAR of the subproject, which you then want to pull in as a dependency? Or what is this "output"?

[Bukama]

Found a text file in the site sources which states:

Packaging plugins are required to call project.getArtifact().setFile( fileYouGenerated ) to properly work in the reactor.

o configuration at plugin-level execution-level

This seems to be related to this here.