Thanks again, Fred. It seems like we're peeling an onion here. See below.
Hi Kenn,
As mentioned in the wiki, please do not use "mvn verify deploy" since
this runs everything up to the verify stage twice (see also
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html).
If you don't want to deploy, use "mvn verify", if you want to deploy use
"mvn deploy".
The only goal for my current build is "clean install -P$BUILD_TYPE -Psign". Do I need to add "verify" and "deploy" goals?
About controlling "when a deploy" happens: the Maven way is to deploy
**every** build. Usually that would be a snapshot build. Only if you are
ready to do a release, you can switch the version number from
1.0.0-SNAPSHOT to 1.0.0 (for example). If the version number does not
include a "-SNAPSHOT" postfix, Maven assumes that you want to do a
release and deploys it to the release repository instead of the snapshot
repository.
Ah, OK. It seems, then, that I would need an explicitly maintained pom.xml file for each of my plugins (many of them are currently generated, I think).
There a tools like the Maven Release plugin that help with the task of
releasing (changing the version numbers in all the required places,
etc), see https://maven.apache.org/guides/mini/guide-releasing.html.
One thing to note about snapshots vs. releases: deployed snapshots can
be overwritten (as in: you can deploy version 1.0.0-SNAPSHOT multiple
times), but deployed releases cannot be overwritten (a second deploy of
release version 1.0.0 would fail, so you would need to release version
1.0.1 instead).
Is it ok, if I post this conversation to the cross-projects mailing list
as well, so others can benefit from the questions and answers?
Done. :)
Regards,
Fred
On 21.12.22 14:11, Kenn Hussey wrote:
> Thanks for the clarifications, Fred!
>
> So, if I won't have the ability to control the timing of deployments by
> putting them in a separate job, what controls whether and when they
> happen? If I add a "mvn verify deploy" step to my existing build, how
> does it decide whether to deploy the artifacts to the release vs. the
> snapshots repository?
>
> Cheers,
>
> Kenn
>
>
> On Wed, Dec 21, 2022 at 4:48 AM Frederic Gurr
> <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>
> Hi Kenn,
>
> All Jenkins instances at the Eclipse Foundation run on our
> cluster-based
> infrastructure and therefore cannot use shared workspaces.
> I have removed the "shared workspaces" section from the wiki to avoid
> confusion.
>
> I'm currently not aware of solutions to split build and deploy into
> separate jobs on a cluster-based infrastructure.
>
> Regards,
>
> Fred
>
> On 20.12.22 16:52, Kenn Hussey wrote:
> > Fred,
> >
> > Thanks for creating the new repositories so quickly in response to
> > https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2413
> <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2413>
> > <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2413
> <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2413>>! I've
> > been reviewing the instructions at
> >
> https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org <https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org> <https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org <https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org>> and noticed the note about shared workspaces and JIPP instances. Can you clarify whether the UML2 jobs are on the new cluster-based infrastructure and, if so, whether that means it's not in fact possible to create separate jobs for building and deploying UML2?
> >
> > Cheers,
> >
> > Kenn
> >
> > On Fri, Dec 16, 2022 at 9:01 AM Frederic Gurr
> > <frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx>
> > <mailto:frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx
> <mailto:frederic.gurr@xxxxxxxxxxxxxxxxxxxxxx>>> wrote:
> >
> > Hi,
> >
> > Every Eclipse project can request their own repo.eclipse.org
> <http://repo.eclipse.org>
> > <http://repo.eclipse.org <http://repo.eclipse.org>>
> > repositories (xxx-releases and xxx-snapshots) to be created by
> > opening a
> > helpdesk issue:
> > https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/new
> <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/new>
> > <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/new
> <https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/new>>
> >
> > All Jenkins instances are set up to deploy to
> repo.eclipse.org <http://repo.eclipse.org>
> > <http://repo.eclipse.org <http://repo.eclipse.org>> by
> > default, but the dedicated repositories need to be created
> first (see
> > above).
> >
> > Instructions for deploying to repo.eclipse.org
> <http://repo.eclipse.org>
> > <http://repo.eclipse.org <http://repo.eclipse.org>> can be
> found here:
> > *
> >
> https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_Nexus_OSS_.28repo.eclipse.org.29.3F <https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_Nexus_OSS_.28repo.eclipse.org.29.3F> <https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_Nexus_OSS_.28repo.eclipse.org.29.3F <https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_Nexus_OSS_.28repo.eclipse.org.29.3F>>
> > *
> >
> https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org <https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org> <https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org <https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org>>
> >
> > We can also assist in setting up deployment to OSSRH/Maven
> Central.
> > See
> >
> https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_OSSRH_.2F_Maven_Central.3F <https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_OSSRH_.2F_Maven_Central.3F> <https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_OSSRH_.2F_Maven_Central.3F <https://wiki.eclipse.org/Jenkins#How_can_artifacts_be_deployed_to_OSSRH_.2F_Maven_Central.3F>>
> >
> > Regards,
> >
> > Fred
> >
> > On 16.12.22 10:38, RADERMACHER Ansgar wrote:
> > > Dear all,
> > >
> > >
> > > in the context of a collaboration with OBEO, we have
> dependencies
> > from a
> > > non-OSGI project to Eclipse plugins, notably Papyrus SW
> designer and
> > > UML2. This means that we cannot use the available p2
> update sites.
> > >
> > > In case of Papyrus SW designer, we pushed a snapshot via a
> "mvn
> > clean
> > > deploy" to a subfolder in repo.eclipse.org
> <http://repo.eclipse.org>
> > <http://repo.eclipse.org <http://repo.eclipse.org>> [1]. In
> case of UML2, we
> > > entered into a discussion what should be the right
> repository to
> > use,
> > > see [2] . The resulting questions are
> > >
> > >
> > > - Which is the recommended repository and sub-folder for
> pushing
> > > plugins? Is that maven central?
> > >
> > > - Do jenkins jobs running on ci.eclipse.org
> <http://ci.eclipse.org>
> > <http://ci.eclipse.org <http://ci.eclipse.org>> have the right to
> > > push/deploy to this repository? This is the case for
> > repo.eclipse.org <http://repo.eclipse.org>
> <http://repo.eclipse.org <http://repo.eclipse.org>>,
> > > but likely not for others
> > >
> > > - Is there a particular setup to do (besides adding
> > > distributionManagement tags to pom.xml)?
> > >
> > >
> > > Sorry, if these questions have already been asked, but I could
> > find the
> > > information.
> > >
> > > Best regards
> > >
> > > Ansgar
> > >
> > > [1]
> > >
> >
> https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/ <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/> <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/ <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/>> <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/ <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/> <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/ <https://repo.eclipse.org/content/repositories/papyrus-snapshots/org/eclipse/papyrus/designer/>>>
> > > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203>
> > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203>>.
> > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203>
> > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=581203>>.>
> > >
> > >
> > >
> > > _______________________________________________
> > > cross-project-issues-dev mailing list
> > > cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> > > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> >
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
> >
> > --
> > Frederic Gurr
> > Team Lead - Release Engineering | Eclipse Foundation Europe GmbH
> >
> > Berliner Allee 47, D-64295 Darmstadt
> > Handelsregister: Darmstadt HRB 92821
> > Managing Directors: Gaël Blondelle, Mike Milinkovich, Michael
> Plagge
> > _______________________________________________
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> >
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>>
> >
>
> --
> Frederic Gurr
> Team Lead - Release Engineering | Eclipse Foundation Europe GmbH
>
> Berliner Allee 47, D-64295 Darmstadt
> Handelsregister: Darmstadt HRB 92821
> Managing Directors: Gaël Blondelle, Mike Milinkovich, Michael Plagge
>
--
Frederic Gurr
Team Lead - Release Engineering | Eclipse Foundation Europe GmbH
Berliner Allee 47, D-64295 Darmstadt
Handelsregister: Darmstadt HRB 92821
Managing Directors: Gaël Blondelle, Mike Milinkovich, Michael Plagge
