I think that is a Maven thing. I've seen parent POMs published
elsewhere. I'm not really sure though as I am not that familiar with Maven.
The parent pom only needs to be published if a child module explicitly references it. In many of the API projects referencing the parent isn't done (the child module directly references the EE4J pom as parent), or when it's done, it's not rarely a mistake.
Kind regards,
Arjan
> I understand your goal is to be able to tag a specific commit for all sub-projects with same version. This will become difficult to maintain. The api and impl will not have simultaneous releases always. For e.g., the api and spec might be in version 4.0.0 and 4.0 respectively and you might need to release impl with version 4.0.1. In this case the parent will be updated to 4.0.1 too.
I agree. The impl needs to be in a separate project. I'm less sure about
the API and spec doc. I can see advantages of releasing together and
separately.
My main aim was to get an updated RC out without the hassle we had with
RC1 when the implementation needed a release. I also want to put an end
to releasing API+impl as a single JAR. I think this module approach is
better than what we had before but I agree it isn't perfect.
I am also trying to work with what has been set up as the "standard" way
to release things through the CI system. That is constraining options to
some extent.
> Even I attempted to clean up the pom in ejb-api[1]. The best solution I have come up is to tag the sub-projects with an individual identifier api-4.0.0-RELEASE, spec-4.0-FINAL
While we are producing RCs I am less concerned. All the artefacts have
moved on since their last release (if any) so releasing an RC2 for all
of them isn't unreasonable.
Once we get to final releases and subsequent updates we will have more
of a problem. Different identifiers for the tags for each module looks
like a reasonable way to go. Not sure how that will work with the CI
process at this state.
Mark
_______________________________________________
el-dev mailing list
el-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/el-dev
