thanks for fast adaptation.
To be honest I think the introduced switch is problematic.
That's why I reopen the message to discuss the pros, cons and alternatives.
Artifact reliability, being consumable:
Each packaging type should create clearly defined artifact content.
Otherwise consuming build results is not possible in a reasonable manner.
The packaging type 'eclipse-update-site' should have a defined result.
Either a complete usable update site (archiveSite=true) or a 'bill of material' like meta description(archiveSite=false).
To provide both types of result from one module separated classified results should be produced <name>.<version>.zip and <name>.<version>-assembled.zip.
Producing the assembled content might be optional in this case.
Furthermore the build should respect the produced result.
It's not reasonable to assemble the full /site folder content and produce p2 meta data in case of (archiveSite=false)
The only reasonable build step in this case would be a site.xml syntax validation.
You state "I do not believe deploying complete zipped eclipse update site to maven repository is something many would want to do"
My question would be "Who is the assumed consumer of the update site description?"
In case there is no user I do not need to build it at all.
At some point in time an update site needs to be materialized. And from my point of view this is clearly a build step.
1. 'eclipse-update-site' is not configurable and always produce a full update site
2. 'eclipse-update-site' is not configurable and always produce a full update site
a new package type 'eclipse-update-site-definition' is introduced which produces a 'bill of material'
3. 'eclipse-update-site' always produce a 'bill of material' as main artifact and can be configured to produce a classified additional assembly result.
(Of course 2 is somehow equivalent to use 'eclipse-update-site' to build the 'bill of material' and introduce a 'eclipse-update-site-assembly' to create the update site)
1. is the easiest, already available solution avoiding the problem with undefined artifact content.
2. is more flexible as it allows to build 'merged' update sites referencing many update site definitions.
Currently I'm not sure whether this is really required.
The good point is that it should be possible to be can be done in a step by step approach.
Introducing 'eclipse-update-site-definition' can be postponed until a real use case is seen.
3. Might be reasonable as well. But I still miss the usage scenario as in 2 and it lacks the step by step introduction possibility of 2.