What's with the BOM/POM now?

[Werner Keil]

Hi,

I don't want to warm up the old thread many weeks after it seemingly died.

However, the more releases are proposed or fired out, the more imminent a proper master dependency management becomes.

Ironically they exist, except with reverse names (compared to what Red Hat, Spring and several others call "BOM")

Microprofile-Config-Parent 1.0

https://search.maven.org/#artifactdetails%7Corg.eclipse.microprofile.config%7Cmicroprofile-config-parent%7C1.0%7Cpom

Is essentially a BOM. It contains only dependencyManagement and even references another BOM (by Arquillian)

MicroProfile BOM 1.1

https://search.maven.org/#artifactdetails%7Corg.eclipse.microprofile%7Cmicroprofile-bom%7C1.1.0%7Cpom

Is not really a BOM. More or less what "Parent" does in many projects. Enforcing dependencies rather than guiding them via dependencyManagement.

So they are of course loaded and retrieved by Maven when building something using that POM even if the component may not use all of these dependencies.

MP Config Parent could and should be used to derive that second "Master POM" (could call that BOM and find another name for the other, at least the content suggests that)

Of course if strict backward-compatibility with 1.1 was desired, maybe the name has to stay, but nobody prevents fixing and adjusting the content of that POM down the road.

Cheers,

Werner

[Ondro Mihályi]

You're right, Werner - the artifact you refer to as MicroProfile BOM 1.1 isn't a BOM but rather a dependency to pull all other MP API artifacts into a maven project with adding just a single dependency into pom.xml

Actually, I suggested that the artifact is renamed from microprofile-bom to just microprofile. It was just too late to do it for MP 1.1 - the PR is here: https://github.com/eclipse/microprofile-bom/pull/15

--Ondro

[Kevin Sutter]

Thanks.  So, what else needs cleaning up with the "microprofile-bom"?  Removing the "-bom" is easy enough.  But, it's still kind of strange to have this in a repo called microprofile-bom.  I'd like to get this cleaned up for MP 1.2.  Thanks.

--  Kevin

[John D. Ament]

Maybe once we're done we rename the repo to just "microprofile"?

[Kevin Sutter]

We currently have one called that...  https://github.com/eclipse/microprofile

But, it hasn't been updated for a long time.  It originally contained some documentation and process-related stuff, but I don't know if it applies any longer...  Maybe we archive that content into another repo (microprofile-archive?) and then rename microprofile-bom to just microprofile?  I'm good with that...  When is proper timing for a change like that?  Before or after 1.2 is released?

Thanks, Kevin

[Ondro Mihályi]

I still see the purpose of having "microprofile" repo as a root repo for other repos. It contains description of the project, processes, resources and links to other repos, basically all the common information which is useful for newcomers and for documentation purposes.

I was also thinking about renaming the "microprofile-bom" to something else, but rather something like microprofile-umbrella. 

Or what about merging the 2 repos into one? The existing "microprofile" repo could still serve its documentation purpose, but would contain subfolders for maven artifacts, like:

microprofile

 |- README.adoc

 |- Processes

 |- Resources

 |- Proposals 

 |- BOM

     |- pom.xml  (a maven BOM module - we don't have any yet), the current microprofile-bom is basically an API dependency)

 |- maven-parent

     |- pom.xml (a parent pom - we don't have any yet)

 |- API

     |- pom.xml (the maven API artifact - this is the current microprofile-bom artifact, which should be renamed to "microprofile" or "microprofile-api" and changed to type JAR instead of POM)

I think it doesn't matter that the release TAG would also cover the documentation part, because that part doesn't contain any releasable files.

--Ondro

[Emily Jiang]

+1 on merging two repos. Basically merge the microprofile-bom into microprofile and still call the repo microprofile.

Emily

[Kevin Sutter]

Merging these two would also have the benefit of forcing us to remember to update the README for the microprofile repo...  It's kind of out-of-date with referencing the repos available...  And, we could get rid of some of the older references to the evolution process...

+1 Ondro.

I'm assuming we would move over the "spec" directory as well (as well as the perform_release directory -- which would need to be updated to take into account these changes).

I'm game to make these changes for 1.2, but I will need some assistance since I'm still not 100% clear on the bom vs parent vs jar vs pom ideas...

Thanks, Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/uc3My-pM8t4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/10ac15da-0cfd-4f21-b89d-2c74f6495d62%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

Sounds like a good move.

Where  is the exact difference between API artifact and parent-pom?

Werner

[Ondro Mihályi]

What I meant by the API artifact is what we have today - an agregator of other MP API artifact to use as a single dependency in a maven web app project.

We don't have a parent pom yet - we could have a pom, which would be used as a maven parent for other poms to share and harmonize some common configuration, e.g. test dependencies, plugin config, etc.

I hope to find some time next week to help merging the repos, but am short of time. The simplest thing we could do is just copy the contents of the BOM repo into a subdirectory in the microprofile repo.

Ondro