Bill Of Materials POM (and which release to start in?)

[Werner Keil]

Hi,

Thought I start a new thread rather than adding it to a 1.0, 1.1 or both.

There has been an understanding we should hold all dependencies together in one place instead of simply using the "Full Java EE Spec" which all the sample apps do right now (hence they don't use MicroProfile at all;-)

Spring under its original groupId org.springframework btw. has something similar for a while now:
https://search.maven.org/#artifactdetails|org.springframework|spring-framework-bom|4.3.6.RELEASE|pom

If it starts with a "pre Eclipse" 1.0 release, then strictly speaking it should not use "org.eclipse.microprofile" yet.
Not sure, if it was a problem or illegal to do so, sure, Wayne could help with that.

If neither microprofile-sample (which was completely migrated to eclipse.org namespace btw.) nor microprofile-conference (there packages still say io.microprofile, but headers are OK now) used this in a 1.0 delivery, there is not much sense in providing a BOM for 1.0. If we don't even "eat our own dogfood"...

Thoughts, volunteers to start it?

Cheers,
Werner

[Kevin Sutter]

Werner,
I agree that we should get his cleaned up and create a "microprofile 1.0" BOM (or POM).  And, then getting our samples and conference app updated to use this instead of the "java ee 7" dependency would be excellent.  I know John has been wanting to work on this, but he could probably use some volunteer(s) to help out.  We need to get this done before a "microprofile 1.1" makes sense.  Thanks!

Kevin

[Ivan St. Ivanov]

Hi everybody,

End of last year I worked together with Dmitry Alexandrov from Bulgarian JUG on a MicroProfile hands-on-lab. Its state is as the state of most projects - almost finished. That is why we haven't brought it to your knowledge yet.

But what we have there is exactly such BOM-like pom project: https://github.com/ivannov/magazine-manager/tree/master/sources/microprofile-dependencies

Maybe we can use that as a starting point?

Cheers,

Ivan

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, 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/7665b2c3-da17-4eb2-8fef-2f374284e3ea%40googlegroups.com.

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

[Kevin Sutter]

Yes, very similar to that (minus the references to the magazine-manager, of course).

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nX3C65gYdI4/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/CACYLA9Fm1RzK8YDtaNOvagaHvgrO5sncp-5hRuZbZMXLHYNV_A%40mail.gmail.com.

[Kevin Sutter]

I have created a top-level microprofile-bom repo in our microprofile.io github.  I was hoping to get our Eclipse github initialized and ready for use, but that's just not moving as fast as I would like...  So, we'll use the microprofile.io github first and then move the contents over to Eclipse when necessary.  Werner, or Ivan, or any other volunteers, please feel free to start on this activity with appropriate PRs.  Thanks!

For now, we should stick with the io.microprofile group id for the POM.  I think this is more consistent with 1.0 happening before Eclipse anyway.  And, then we can adjust to the org.eclipse naming convention later.

Kevin

On Monday, February 13, 2017 at 10:45:11 AM UTC-6, Kevin Sutter wrote:

Yes, very similar to that (minus the references to the magazine-manager, of course).

On Mon, Feb 13, 2017 at 9:35 AM, Ivan St. Ivanov wrote:

Hi everybody,

End of last year I worked together with Dmitry Alexandrov from Bulgarian JUG on a MicroProfile hands-on-lab. Its state is as the state of most projects - almost finished. That is why we haven't brought it to your knowledge yet.

But what we have there is exactly such BOM-like pom project: https://github.com/ivannov/magazine-manager/tree/master/sources/microprofile-dependencies

Maybe we can use that as a starting point?

Cheers,

Ivan

[Kevin Sutter]

Maybe I should give the link so that everyone knows the proper location...  :-)

https://github.com/microprofile/microprofile-bom

[Ivan St. Ivanov]

Hi Kevin,

There you go:

https://github.com/microprofile/microprofile-bom/pull/1

Cheers,

Ivan

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/bc9b358b-b379-48ba-887c-b74bb76fb304%40googlegroups.com.

[Kevin Sutter]

Thanks, Ivan.  Made a couple of comments, but right along the lines of what I was looking for.

Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@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/7665b2c3-da17-4eb2-8fef-2f374284e3ea%40googlegroups.com.

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

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nX3C65gYdI4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@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/CACYLA9Fm1RzK8YDtaNOvagaHvgrO5sncp-5hRuZbZMXLHYNV_A%40mail.gmail.com.

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

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Werner Keil]

Just trying some myself, 

The PR Ivan submitted seems a bit ahead of its time more 1.1 than 1.0 (which based on samples or conference app seems like it's supposed to be Java EE 7 compatible, or not?)

Cheers,

Werner

[Ivan St. Ivanov]

I think I got it, Kevin. Please check again :)

Werner, why do you think it is 1.1?

To unsubscribe from this group and stop receiving emails from it, 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/6caefc16-d120-4108-b57b-c8b8e25a6525%40googlegroups.com.

[Werner Keil]

Because all the current apps use Java EE 7 and https://github.com/microprofile/microprofile-bom/pull/2 is based on those versions.

It guarantees the greatest compatibility, not every vendor and container may have updated each of the JSRs just because a MR is there.

[Kevin Sutter]

I like parts of both PRs...

I don't think we have to nor should adhere to strict Java EE 7 spec levels for these dependent APIs.  CDI 1.2 was out just barely after Java EE 7 completed.  I consider it the "defacto version" of CDI.  Most (all?) application servers that claim Java EE 7 compliance are testing with CDI 1.2 implementations.

The 2.0.1 update for JAX-RS also came out just shortly after Java EE 7 completed.  And, since it's a minor update revision number, I would also vote to keep that version in our POM file.

At least we all agree with JSON-P at 1.0...

I also think the <organization> and <url> should reference microprofile.io instead of Eclipse Foundation.  When we announced and released MicroProfile 1.0 last fall, we were just considering Eclipse Foundation along with other foundations as our landing spot.  So, we shouldn't reference Eclipse at all with the 1.0 offering.

The updates Werner did for the .gitignore also look good. 

So, if we can compromise and get one or both of these PRs in sync, then maybe we can merge and move on.  Thanks for your help!

Kevin

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/c91c3659-370c-476c-a2ab-542ab8e8c91e%40googlegroups.com.

[Werner Keil]

Thanks.

As for the license header in the POM itself, if it's a merge of both PRs, then maybe stick to the "Red Hat, IBM and others." pattern. I based mine on microprofile-samples where the headers quoted the initial contributor.

Werner

[Werner Keil]

Thanks.

As for the license header in the POM itself, if it's a merge of both PRs, then maybe stick to the "Red Hat, IBM and others." pattern. I based mine on microprofile-samples where the headers quoted the initial contributor.

Werner

[Emily Jiang]

+1 on specifying CDI 1.2 not CDI 1.1. As you may know, CDI 1.1 has significant flaws on bean discovery mode, conversation resolution, unclear event resolution. Therefore, within a year, CDI 1.2 as a maintenance release was published to replace CDI 1.1. Both OWB and Weld implements 1.2 and ignores CDI 1.1.
WebSphere Liberty supports CDI 1.2, so does WildFly.

Therefore, it does not make sense to state CDI 1.1 in the MicroProfile 1.0 release.

Emily

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ivan St. Ivanov]

Hi everyone,

I updated my pull request with Werner's changes mentioned by Kevin. You may review that when you have time.

Cheers,

Ivan

[Werner Keil]

What about JAX-RS? Is 2.0 also flawed/broken or ignored now?

As Ivan works for SAP, I trust the "usual naughty" question about his ECA can also be answered?;-)

Cheers,
Werner

[Ivan St. Ivanov]

Hi Werner,

Yesterday I signed my ECA. And I don't work for SAP anymore. As of last December I am self employed :)

Cheers,

Ivan

To unsubscribe from this group and stop receiving emails from it, 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/7067a27e-806b-4a7f-b148-47549df431c2%40googlegroups.com.

[Werner Keil]

Hi,

Good, thanks, then welcome as fellow Individual ;-)

Werner

[Ondrej Mihályi]

Hi,

Have you considered defining a real MicroProfile-API 1.0.0 dependency instead of just a BOM? In the same way as javaee-web-api is used?

I don't see much sense in using BOM in a project and then again specify each dependency separately.

I mean, we could have a BOM if someone wants to specify exact dependencies granularly, but to get started quickly with a new MP project, I as a developer would like to have the option of defining a single MP-API dependency and start coding.

What do you think?

--Ondrej

Dňa pondelok, 13. februára 2017 15:44:24 UTC+1 Kevin Sutter napísal(-a):

[Ivan St. Ivanov]

Hi Ondrej,

The pom.xml is defined in almost the same way as the pom.xml of javax:javaee-api. And as I put it in the README, you can just add a dependency to it in your project and start coding against the three APIs:

<dependency>

    <groupId>io.microprofile</groupId>

    <artifactId>microprofile-bom</artifactId>

    <version>1.0.0</version>

    <type>pom</type>

    <scope>provided</scope>

</dependency>

This is exactly what we do in the hands on lab.

Is it the packaging type that bothers you? You think we should change it to jar (or better said, remove it)?

Regards,

Ivan

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, 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/771edd5b-7939-46ce-8a41-95574d2a20d1%40googlegroups.com.

[Werner Keil]

Sorry but what API does 1.0 define?

There is no genuine API code in MicroProfile 1.0. Like the Java EE 7 web-api, only much smaller it's a BOM.

A 1.1 BOM could and should offer further "genuine" APIs like Config or others.
Which of those would be mandatory and which optional to be "MicroProfile Compatible", that's another story.

Werner

[Werner Keil]

To me POM sounds exactly right.

Even for future releases that may contain further APIs both inside and outside Microprofile, but that should be under the "org.eclipse" umbrella then.

Werner

[Ondrej Mihályi]

Thanks, Ivan, for the explanation.

While I though it should be possible to use the same artifact both as a BOM and as a dependency, I was not sure if it is the case. General usecase with BOMs is that they are imported to provide versions for dependencies.

I think we can go with the `pom` package type, if we promote it enough. We need to let people know that they can use it this way. Otherwise people starting with MP (at least thos with Java EE background) would be seeking a `provided` dependency. Or just import it as a BOM, not knowing about this option.

For example, our example applications definitely need to use it as a dependency and not import it as a BOM.

P.S. I suggest to remove the `-bom` suffix in the artifact name if we want to promote using it as a dependency. People wuld really expect our main artifact's group and name this simple: io.microprofile:microprofile (org.eclipse.microprofile:microprofile in the future)

--Ondrej

Dňa utorok, 14. februára 2017 10:32:08 UTC+1 Ivan St. Ivanov napísal(-a):

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ondrej Mihályi]

I don't get your point, Werner.

The javaee-web-api artifact has JAR package type and not POM, therefore it is not a BOM.

I don't see any reason to not follow this pattern. However, we may support both depdency and BOM pattern, as Ivan already explained. But even in that case, using the artifact as a dependency should be preferred, and therefore the artifact should be renamed from 'microprofile-bom' to just plain 'microprofile'

--Ondrej

Dňa utorok, 14. februára 2017 10:32:26 UTC+1 Werner Keil napísal(-a):

[Ivan St. Ivanov]

Hi Ondrej,

I see what you mean. And I think you are right and I confused both concepts:

• BOM that you import into your project's poms to derive the dependencies versions (which dependencies you add explicitly)
• javax:javaee-api like project, which you just add as a dependency and you're done

If you ask my personal opinion as a developer (which is non-binding in terms of Eclipse project voting), I would go for the second option. Which means I would have to make the following changes in the pom.xml:

• Remove packaging type
• Remove any mentions of BOM or "Bill of Materials" to avoid confusion

But let's see what others think.

Regards,

Ivan

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, 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/2f3314a2-7e1d-4497-ba07-3a30f7bb72e1%40googlegroups.com.

[Werner Keil]

In that case I did have a similar conversation with Kevin about that yesterday, https://github.com/microprofile/microprofile
would have to be renamed first to make room for this now "non-bom" ;-)

Keeping the repository name and then declaring a totally different artifactId would be much worse, so either change https://github.com/microprofile/microprofile into https://github.com/microprofile/microprofile-docs
or whatever, or stick to https://github.com/microprofile/microprofile-bom.

Which one is preferred?

More importantly, the javaee-api JAR is an "Uber-JAR" so it has every single javax.* class held together in a big JAR.
It is safe and approproate to do so under "javax.javaee-api" or whatever, but IMHO we must not do that for io.microprofile (most importantly everyone who is a JCP member would violate Java EE Compatibility by "subprofiling" which only Oracle may do) so please can we stick with the BOM here?;-)

Werner

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Werner Keil]

All you need is to look at the average Eclipse "plugins" folder.

It contains separate JARs (bundles because they're OSGi enabled) like javax.inject_1.0.0.v20091030.jar just to use JSR 330 (underneath CDI) as example.
You'll never find a project (OK Spring DM later Gemini briefly tried that with "com.spring.org.apache.commons...." and similar OSGi enabled standard libs) with an "Uber JAR" like "org.eclipse.projectXYZ_1.0.0.v20170214.jar" that contains "javax.inject" packages instead. So whether MicroProfile JARs are to be used on the server or in RCP environments, this Eclipse project must not do either.

Werner

[Ondrej Mihályi]

I agree that in that case the BOM repository should be renamed.

But it shouldn't be renamed into plain microprofile.

The idea behind microprofile repository is to provide the "main" repository to explore the MicroProfile project and all it resources, especially for newcomers. It should explain what MicroProfile is, what are other repositories for, info about releases and getting started guides, etc. But we may move the maven pom.xml into a subfolder in the microprofile repo, and that subfolder would be dedicated to maven. I think we don't need a separate repository just to store a single pom.xml.

If you think that we need a separate repo for global MP maven artifacts like the BOM discussed, we should name it differently than microprofile, e.g. microprofile-maven. 

--Ondrej

[Kevin Sutter]

I don't think Ondrej's comment was about the name of the repo, but the name of the artifact...  It may not be the most consistent, but we can have the repo called "microprofile-bom" and the artifact be named "io.microprofile:microprofile" (dropping the "-bom").   And, I'm fine with this inconsistency for this initial drop.

Kevin

[Werner Keil]

As long as it's a POM artifact not an "Uber-JAR" subsetting Java EE 7 or 8 (before that's done by the Platform JSR itself) The name is not so important.
The groupID at the very least should change from "io.microprofile" to "org.eclipse.microprofile" as mentioned once it gets moved to Eclipse, so deviating the artifactId, too, sure, if you think it's better, call it what you feel works best for now.

Werner

[Mark Struberg]

I think the problem is neither the name nor the type but the usage. 

A BOM typically gets imported in the dependencyManagement section and serves to unify versions.

Do we really need this? I mean different microprofile offerings might use different JAX-RS API jars even (due to licensing).

What would make sense is a common parent which has a few 'organisation' settings.

Like a shared checkstyle-maven-plugin setting, some license checks, a unified distributionManagement, etc

That would be used as <parent>.

I think I already explained this in another thread.

[Ondrej Mihályi]

I agree that the usage is important.

But I feel we need to clarify the usecases here.

In this thread, so far, we've discussed an artifact for MicroProfile users to get started. I think this was the usecase which the initial BOM suggestion was trying to address. And we've concluded that, instead of a BOM, it is more appropriate to create a "provided" dependency, similar to javaee-web-api, which would just contain the API guaranteed by MP. 

I think that you, Mark, are addressing an internal MP usecase to provide some common configuration for all MP poms. In that case I agree that having a parent pom is useful. 

This only shows that we have need for multiple pom artifacts. A question is whether we want to keep them in separate repositories, or we will rename the repo micorprofile-bom to e.g. microprofile-maven, and keep more artifacts in it, each in a separate directory.

What do you think?

--Ondrej

Dňa streda, 15. februára 2017 12:32:50 UTC+1 Mark Struberg napísal(-a):

[Kevin Sutter]

Mark, I agree and disagree with your post...  First off, I agree that we should have some top-level parent repo that kind of ties everything together.  I don't know whether it's the microprofile repo, or the microprofile-bom repo, or maybe we create a microprofile-parent repo.  But, something that a user can start with and then traverse our tree of related repos.

On the disagree aspect...  I believe we do need a "microprofile pom" that makes it extremely easy to get started developing MicroProfile applications.  You may think of it only as a "convenience" pom since anybody can do this today by pulling in cdi, jax-rs, and json-p.  But, by us providing this MicroProfile pom, it quickly removes the question marks on which versions of these various APIs we are endorsing.  For example, we don't want people to think that MicroProfile 1.0 supports CDI 2.0 already.

Also, I think we need to be explicit on the versions of these API jar files just to have a consistent story.  If a customer wants to use a different version than what we have declared in our pom, then let them.  They are back to the pre-MicroProfile pom days and in DIY mode.

Thanks, Kevin

[Kevin Sutter]

I just merged in a version of Ivan's PR.  Now we have something to experiment with and make "real". 
https://github.com/microprofile/microprofile-bom

To that end, I see a few more work items...

o  Deploy this pom for MicroProfile 1.0 into maven for general access and usage.  At this point, I don't know that we have a general release process since it's already been announced.  But, we need to get this into a maven repo.

o  Modify our usage in the samples and conference app to use this pom dependency instead of the uber java ee 7 pom.

o  Advertise this via our MicroProfile 1.0 collateral, which I know John is working on.

I don't care if we break these efforts into separate discussion threads, or just continue to use this one.  Let us know if you are volunteering for any of these activities.  Let's try to get a consistent, public story available for MicroProfile 1.0 as quickly as possible.  Thanks!

Kevin

[Werner Keil]

>Do we really need this? I mean different microprofile offerings might use different JAX-RS API jars

As Kevin said that would pretty much undermine what MicroProfile tries to archive.
Of course we know there are vendor specific "Uber-JARs" like "org.jboss:javaee" in different versions, which do not deviate from the official Java EE API JARs. Starting with Java EE 7 this has been a lot less common. And to allow a vendor-neutral development and delivery of MicroProfile apps there must be one such POM for each MicroProfile version.

Several vendors call it BOM, not just Red Hat, Pivotal also started. In theory you could also combine the two and put those kinds of dependencies into a "parent-pom". Those using a BOM pattern also clients I work with have a separate BOM which may be used in multiple projects and modules, each under a separate hierarchy, so there are multiple abc-xyz-parent POMs but usually just one abc-bom unless it is a very large system that requires multiple BOMs.

If every single MP project was sure to inherit from the same parent POM, then those ingredients could be defined there under dependency management. Should say microprofile-config, microprofile-samples, or other future artifacts require a separate parent POM then a BOM that can be used by each of those sounds better.

Regards,
Werner

[Ivan St. Ivanov]

Hi Kevin,

I can do the first two items, no problem. And contribute to the third with whatever I can.

Just, for Maven central, someone needs to go through the whole process (starting from an issue here https://issues.sonatype.org/projects/OSSRH). I've done that once for a Bulgarian JUG artifact, so technically I can do that again. But maybe it should be someone from the "core group"?

Regards,

Ivan

To unsubscribe from this group and stop receiving emails from it, 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/9df8bc2b-47e3-44c1-8a33-8ed9d602d3e4%40googlegroups.com.

[Kevin Sutter]

Ivan,
Thanks for volunteering.  And, yes, I knew about the Sonatype issue process.  I was hoping someone could pick this up and run with it.  I can understand your hesitancy though.  Maybe you are more of the "core group" than you think you are...  :-)  If nobody else picks this up, then maybe you and I could do it.

Kevin

[Werner Keil]

Also did for a couple of JSRs and other Open Source projects before. Let me know if you need a hand.