maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (MRELEASE-362) Support tagging nested projects
Date Sun, 05 Aug 2018 09:27:00 GMT

     [ https://issues.apache.org/jira/browse/MRELEASE-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Scholte reopened MRELEASE-362:
-------------------------------------

Discussed this with [~paranoiabla] 
{quote}My current proposal:

the start situation is a folder containing several checked out projects.
 the folder contains an aggregator pom, which is NOT under version control.

release:prepare should start as normal, but it should end with a commit+tag+commit on every
checked out folder.

release:perform uses target/checkout, where you copy the aggregator-pom.
 And you also check out the projects by tag. Ensure they're using the same directory-name.

That should be about it. The wording is probably easier compared to the implementation.

Have a look at project-utils[1]. It should help with determining what kind of project every
pom is.
 It hasn't been released yet, but it was written to help the maven-release-plugin
{quote}

> Support tagging nested projects
> -------------------------------
>
>                 Key: MRELEASE-362
>                 URL: https://issues.apache.org/jira/browse/MRELEASE-362
>             Project: Maven Release Plugin
>          Issue Type: Improvement
>          Components: scm
>    Affects Versions: 2.0-beta-6
>            Reporter: Michael Johns
>            Priority: Minor
>
> We have a non-standard situation here.  I can _almost_ get Maven to support it, but I
can't cross the last hurdle of tagging and releasing the project.  The business case is that
we have a core product that is built with Maven and a customer implementation of that product
that is also built with Maven.  Each builds just fine on their own.  They are both first-class
projects.  The second project depends on the first.  Each project has multiple modules.
> The situation we want to support is parallel development of both projects.  If a developer
makes a change in the Core product, we don't want to have to go through a tag/release cycle
in order to pull that change into the Customer project.  (Yes, this is non-standard and not
the best idea, but we have few options due to time and resources.)  To accomplish this, we
linked the second project into the first using svn:externals.  We then created a new profile
in our pom.xml that pulls in the "parent" pom.xml from the second project as a module.  Let
me see if I can visually represent it:
> Core Product
>   - Core Product Module 1
>   - Core Product Module 2
>   - Core Product Module 3
>   - Customer Project  <== linked via svn:externals and included as a module in the
"Core Product" pom.xml via a profile
>     - Customer Project Module 1
>     - Customer Project Module 2
>     - Customer Project Module 3
> Note that the version numbers for the Customer projects are different than those in the
Core Product.
> This works like a champ when running most plug-ins against it.  For example, I can run
the eclipse plug-in against it (using the special profile), and all project dependencies are
resolved correctly between the two.  The problem comes when I try to tag and release them
together.  This is the command I'm using:
> {code}
> mvn -P customer --batch-mode -Darguments="-P customer" -DpreparationGoals="jar:test-jar
install" -Dresume=false -Dgoals="deploy site-deploy" clean install release:prepare release:perform
release:clean
> {code}
> The "customer" profile is the one that pulls in the customer projects.  This command
(executed in Continuum) works like a champ to release our other projects.  But when I run
it against this project, here's what happens:
> # Updates versions on all projects (both Core and Customer) to drop SNAPSHOT
> # Installs all projects
> # Tags Core project
> #* Does *not* tag Customer project (*this is the problem*)
> #* Tagged Core project still points to external projects' trunk (this is a SVN issue,
not a Maven issue)
> # Updates versions on all projects (both Core and Customer) to next SNAPSHOT
> # Checks out tagged project
> #* Project still points to Customer project's trunk (again, a SVN issue)
> # Builds projects
> #* Build fails on external projects because they point to the new SNAPSHOT version of
main project (due to SVN issue)
> So ignoring the SVN issues, here's what I'd like to see supported by the release plug-in:
> * When tagging, also tag the Customer project that is included via a module.  It is a
stand-alone project, so it has all of the necessary information in the pom.
> I know this is a bit convoluted, so please let me know if you need clarification.  I
could potentially attach some of our pom files to show how our project is set up, but a big
part of this is the directory structure (which we create using svn:externals, but it doesn't
have to be done that way), so I'm not sure how useful it would be.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message