Hi Tamás,
thanks for following up!
So let me try to provide some context:
1) the javadoc archive contains only a subset of the classes from the project
2) the jar as the main file of the project is built in a normal build and then
in a later build stage outside of the maven build packaged into a container
image (in a GitHub action)
3) we don't build snapshots, each build produces artifacts with release version
if you will, but we don't deploy them – each container image contains the jars
with 'release' version – the only difference between a 'snapshot' and 'release'
image is the tag version, the files inside the image are the same (have the
same (release) version
4) we're deploying the javadoc archive to GitHub Packages to share it with
others
5) the POM of the javadoc archive in GitHub Packages has the wrong packaging
(jar default packaging), but this was acceptable for us (we didn't care)
It seems for my use case I should use deploy:deploy-file instead. Tamás, could
you point me to an example how to use it as part of a build with the other
steps as you suggested below? I guess I was considering it not a fit because I
assumed I had to provide all the parameters again vs. with deploy:deploy (pre
3.0.0) all parameters were set for me.
Initially I tried to find a solution with a short command to produce and deploy
the javadoc archive manually. However, the next step is anyway to automate this
process and then it's less of a problem to split creation of the javadoc
archive and deploying it into two steps – and use deploy:deploy-file with all
needed parameters ('file', 'url', etc.) – which I intended to avoid, I thought
I'd rather configure it in the POM (like distributionManagement) instead of
command arguments.
Thanks again, Tamás, for guiding me here!
It helped me understand, what we're currently doing needs to be changed, given
the changes to maven-install-plugin and maven-deploy-plugin. I'm still inclined
to think our original use case is valid (deploy one part of a project even if
it's in incomplete state), but can understand the reasons why this option has
been cut off and the alternative might be more than just a workaround.
Thanks
Bernhard
PS: my initial question showed up twice accidentally – as a novice I posted
first without subscribing. Subscribed, posted again and you all thankfully
responded already. And then my initial post finally also made it to the list…
Bernhard Schuhmann
Senior Software Engineer
Jedox
Bismarckallee 7a
79098Freiburg im Breisgau
Germany
Jedox GmbH
Chief Executive Officer (Geschäftsführer): Florian Winterstein
Place of Business: Freiburg i. Br. | Registry Court: Amtsgericht Freiburg | HRB
723467
[TM.V06112018]
Von: Tamás Cservenák
Datum: Donnerstag, 23. Februar 2023 um 12:23
An: Maven Users List
Betreff: Re: [m-deploy-plugin] Deploy javadoc archive only
Howdy,
so, personally I am in "limbo" about this, and let me explain why.
First let me state that I lack some context here:
- why is Bernhard doing this? (is he editing and then "testing" the edited
Javadoc? I mean, why is roundtrip needed [the deploy])
- where is he deploying it (some shared local repository? or his personal
one-man-show MrM?)
- is the project he works on a RELEASE or a SNAPSHOT?
- etc
And about my limbo opinion:
I do agree with the part of the original discussion, about the "general
repo hygiene" bit, that with pre-3.9.0 Maven this project would deploy
"incomplete" (the POM would state packaging is JAR, but there is no JAR
present). A lot of further conclusions depend on the context above (where
is deployed, etc). I have a feeling like Bernhard should do something like
this instead:
$ mvn javadoc:javadoc assembly:single deploy:deploy-file
As "deploy" means "deploy the project", that is obviously in "incomplete
state". One more point for this is Bernhard saying "I am building a JavaDoc
archive for a jar", so he also states he is NOT building the whole project
intentionally, only one archive from it.
OTOH, I disagree with implementation (or the behaviour change) of both
issues (see below), as for me, this really looks like some sort of
"validation" (or "sanity check"), and install/deploy plugins should NOT be
smart at all, in fact, they should be as "dumb" as possible. If there is
some validation needed, these plugins are for sure not the place to have
them.
Issues:
https://issues.apache.org/jira/browse/MDEPLOY-205
https://issues.apache.org/jira/browse/MINSTALL-118
T
On Wed, Feb 22, 2023 at 8:20 PM Greg Chabala wrote:
> Am I correct in my reading, that they found a similar use case for why
> installing/deploying without a main artifact was allowed, and thus why a
> test was guarding that behavior, but then decided it wasn't 'the Maven Way'
> enough and ripped it out?
>
> That makes it seem like a dummy jar is the only s
