MicroProfile BOM, etc

[Ken Finnigan]

It's time to start a new thread on the state of the current MicroProfile BOM.

Previously we had [1] and [2] threads, possibly more, as well as an issue discussion [3].

To try and fix this once and for all I'd like to propose the following:

1. Rename https://github.com/eclipse/microprofile-bom and artifact to be `microprofile-api`
2. Create a fresh repository for https://github.com/eclipse/microprofile-bom that can have a true `microprofile-bom` with dependencies in dependencyManagement section for scope=import usage

For me these changes solve the issues raised in [1] and [2].

Firstly it retains the idea of a dependency to bring in all the MP APIs for use in a developers project, similar to the `javaee-web-api` artifact from Java EE. As the artifact id has already been changed to `microprofile`, we could consider sticking with that as opposed to changing to `microprofile-api`.

Secondly, we then have a true BOM for implementors to use the correct versions of dependencies more easily.

Thoughts?

Ken

[1] - https://groups.google.com/forum/#!topic/microprofile/UINnSKJBtrI

[2] - https://groups.google.com/forum/#!topic/microprofile/nX3C65gYdI4

[3] - https://github.com/eclipse/microprofile-bom/issues/9

[John D. Ament]

+1 on microprofile-api.

+0 on the actual bom, not sure it's very useful.  Would rather focus on microprofile-parent.

John

[Werner Keil]

-1 on microProfile-api.

The name is misleading, as the POM artifact itself does not define any API. Check http://search.maven.org/#search%7Cga%7C1%7Cjavaee-api the vast majority of them (also Apache projects btw;-) are JAR projects that offer mor than just a POM. 

The few are very old.

Many projects make proper use of a real BOM. 

It depends on what you are dealing with. MicroProfile-parent is strictly for internal usage, if using MicroProfile should be advertised and made easier, then a real BOM (the name does not count, but most in the Open Source world just call it that way, so why not call a Rose a Rose?;-) is what someone should also focus on.

Werner

[Werner Keil]

+1 on 2) I guess they are not two options but rather steps proposed?

Again, I cannot see a value in having 3 POMs (microProfile-parent, MicroProfile-api and MicroProfile-bom) 2 are enough.

[Kevin Sutter]

I'm a big +1 to get this all resolved...  :-)

I also agree that I don't want to proliferate the issue by creating yet another project/repo that overlaps slightly with other repos (ie. microprofile-api).

It seems that we have a few things that we're trying to manage (feel free to add to this list):

• MicroProfile spec (currently in microprofile-bom)
• MicroProfile build scripts (currently in microprofile-parent)
• MicroProfile top level pom file (currently in microprofile-parent, but not used by components yet)
• MicroProfile bom (a "bad version" is in microprofile-bom)
• MicroProfile api pom for maven (currently in microprofile-bom)

We also have a microprofile project/repo that is not really being used.  It's kind of being used a "top level" project, but we're not maintaining it.  Much of the information is out of date.  Should this be re-purposed or even removed?

-- Kevin

[Ondro Mihályi]

That's a great summary, Kevin.

It's clear that we already have 3 similar repos (microprofile, microprofile-bom and microprofile-parent)
I wouldn't create more, rather I would even reduce them into 1 or 2 repositories.

The parent an build scripts are only for internal purposes. All the others are basically related to the public MP release: Spec, BOM, API, Documentation (README)

I suggest to merge microprofile-bom and microprofile repos into a single microprofile repo and create a subfolder in that repo for every component. It would keep all umbrella-related components together and simplify keeping all of them up to date with every new release.

Therefore I suggest:

- microprofile repository
   - MP spec (move from microprofile-bom)
   - MP API artifact (move from microprofile-bom)
   - MP BOM artifact (move from microprofile-bom)
   - basic information about MP in the top level README and linked documents (exist in microprofile repo, but should be updated and reduced to the necessary minimum (more details should be in the wiki)

- microprofile-parent
   - MP build scripts
   - MP parent artifact

- microprofile-bom
   - discard after all resources moved to the microprofile repo

--Ondro

[Werner Keil]

+1 

That sounds like a good idea and goes along repositories like https://github.com/wildfly/boms or https://github.com/weld/api (which also holds multiple repositories including a BOM despite the name "api" for the parent)

Werner

[Emily Jiang]

IIUC, Ondro, you are suggesting to rename the current microprofile-bom to microprofile and potentially it can be expanded to store more info.

I think it is a reasonable approach.

Emily

[Ondrej Mihályi]

Yes, Emily, you understood correctly.

--
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/DAemBIWP9mI/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/b5b4adf8-49fa-4481-9bba-c9eca3a68e48%40googlegroups.com.

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

[Emily Jiang]

By the way, I had a further thought on this:

If we go ahead to rename microprofile-bom -> microprofile
then we have
microprile repo
and
microprofile-parent (this is to store some useful scripts)

Will this naming cause confusion? Will renaming microprofile-parent to microprofile-utils make the structure better understood?


microprofile (overall repo)
microprofile-config (individual specs)
microprofile-fault-tolerance
microprofile-jwt
...
microprprofile-utils (provide useful scripts)

just my 2cents

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.

[Ondrej Mihályi]

I agree that renaming the microprofile-parent repo to microprofile-utils, or maybe even better to microprofile-dev is appropriate.

I like microprofile-dev more, because "dev" is widely used to mark resources for developers and not for end users (e.g. "dev" mailing lists). And the suggested content (parent pom and build scripts) is exactly developer resources.

Ondro

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/ac3ee2d9-4477-483e-b840-804b6156525e%40googlegroups.com.

[Emily Jiang]

sounds good.

Emily

[Werner Keil]

Having a choice between "utils" and "dev" I would also prefer "dev". "utils" sounds a bit too generic.

Will "microprofile" then be what many other programmes call "-bom" or should "microprofile" be the "parent" POM and another module a true "BOM" in the form everyone understands as such?

Werner

[Kevin Sutter]

With the MP 2.0 release proposal gaining steam, it's about time we clean up our repositories and their respective content.  I've been reviewing this current thread, along with the -parent thread discussion, and -bom issue #9.  I'd like to propose the following actions...

1. Rename microprofile repo to something like microprofile-background or microprofile-legacy or microprofile-attic.  I really don't see anything in this component that we use or reference, but I hate to just throw it out.  And, I really don't want it cluttering up the proposed content for the re-purposing of this name (next bullet).
   
2. Rename microprofile-bom to microprofile.  We have already renamed the maven artifact to get rid of the -bom suffix, we should have a corresponding repo with the same name.  This repo would contain the overall, umbrella specs for MicroProfile.  And, it would continue to contain the pom file necessary to produce the MP release artifacts.  (Basically the same content as microprofile-bom contains now.)
   
3. There has been discussion about renaming microprofile-parent to microprofile-dev (or -utils).  I don't agree.  The intent of -parent is to provide the parent pom for our components to reference.  And, it provides our common build and deployment scripts.  I think that's the perfect content for a "parent" repo.

If we are good with these type of changes, then would free up the microprofile-bom repo for someone to actually create a real "Red Hat style" bom.  Since I failed miserably with this during the 1.x effort, I would like to leave this part of the exercise up to someone from Red Hat (or at least someone with more experience with this type of bom creation and maintenance).

I'd like to get this cleaned up before we kick off the 2.0 release processing.  I'll take the lead with getting these changes in place as long as I can get some agreement on the direction.

Thanks, Kevin

[Werner Keil]

Kevin,

+1 for all three.

There is no strong preference in calling it bom or not as long as it serves the purpose. Especially if aspects of Java EE 8 were added in 2.0 not all application servers fully support the entire Java EE 8 scope yet so pulling the relevant bits in a clean way beside exposing the matching internal features becomes even more important then.

Unlike EE4J I am not a committer here yet but happy to help with PRs.

Werner

[Ondro Mihályi]

Hi Kevin,

+1 I've wanted do something similar a while ago.

Except, I think there's still some relevant information in the "microprofile" repo (README, Resources and maybe build-tools).

Therefore this is what I suggest:

1. Instead of renaming "microprofile" only move unused resources into a separate folder name "attic" or "archived"

2. move the content of "microprofile-bom" into "microprofile"

3. leave "microprofile-parent", maybe rename it to "microprofile-maven-parent" or "microprofile-build-parent" to clearly indicate that it's related to maven/build as we may have multiple similar repositories (e.g. for bom) and a common prefix would group them together

4. for each maven artifact, we create a separate repository (bom, build plugins, etc)

Initially, I thought that all maven artifacts can be in one repository to avoid too many repositories containing just a few files. But I agree it's easier to work with if we have a separate repo for each artifact.

--Ondro

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/d334259e-e0c8-472f-8475-9f646c157c78%40googlegroups.com.

[Kevin Sutter]

Thanks, Ondro and Werner, for your support.

Ondro, I would probably move all of microprofile content to a separate folder as "attic".  Then, we could move what we need or want out to the usable environment as needed.  Instead of spending time now trying to figure out what's needed.  We can archive everything now and then pull things out as needed.  Okay with that approach?

If we go this route and then I move all of the microprofile-bom to microprofile, we could leave microprofile-bom as empty for future population of a true "red hat" style bom.  I could put an "under construction" readme in place and point people at the microprofile repo for the old information.

I'll leave -parent as is for now.  We can adjust that later, if necessary.

I'd like to get some additional +1's on this direction before I start making these changes.  I think this is the right time to get this cleaned up before we start on the MP 2.0 track.  Thanks for all the suggestions!

-- Kevin

[Emily Jiang]

+1 on a) moving microprofile to microprofile-attic b) rename microprofile-bom to microprofile

As for the microprofile-parent, I disagree on the name as I had been in the past. I like what Ondro's suggestion to get it renamed to microprofile-build-parent, as the microprofile-parent name suggests it is the parent for all of the microprofile specs, which is not the case.

Thank you Kevin to pick this up to get the repo names sorted!

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3eb3ac0f-be6c-4651-a1b1-04e464d369ae%40googlegroups.com.

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

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[Kevin Sutter]

Emily,
My point is that I don't want to debate the name of the -parent repo as part of this clean-up and prep for MP 2.0...  I think we can leave -parent as is for now and the renaming of that repo can be done on a separate thread.

Thanks for the other confirmations!

-- Kevin

[Ondro Mihályi]

+1

I'm OK with moving everything to attic for now and also with everything else you suggested in the last email, Kevin

--Ondro

Dňa po 16. 4. 2018, 15:15 Kevin Sutter <kwsu...@gmail.com> napísal(a):

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d334259e-e0c8-472f-8475-9f646c157c78%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 "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/DAemBIWP9mI/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/3eb3ac0f-be6c-4651-a1b1-04e464d369ae%40googlegroups.com.

[Emily Jiang]

ah, ok. Thanks Kevin! Agreed. I thought you disagreed the name change for microprofile-parent. When I get some time, I will rename the microprofile-parent:o.

Thanks

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/51955253-9747-404d-9d09-7b7dc0679190%40googlegroups.com.

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

[Kevin Sutter]

Okay, I'm starting to make the changes...  First one is to move the majority of the -microprofile repo to an "attic" directory.  After that is reviewed (volunteers?), I'll get that merged so that move of the spec material is easier.  Thanks!

https://github.com/eclipse/microprofile/pull/24

-- Kevin

[Kevin Sutter]

Next question...  When I move the spec content from microprofile-bom to the microprofile repo, should I attempt to keep the history?  Just moving the content and forgetting about the history is easiest, of course.  It looks like I can transfer the history (google), but I haven't done that myself.  So, any suggestions on how to do it or even if it's necessary, I'm all ears.

The reason for this question is because the current MicroProfile umbrella content in maven points back to the microprofile-bom repo.  If I move the history, does that negate these links?  To that end, I am leaning towards leaving the history where it's at and just copy the content over to the microprofile repo.

Thanks!
Kevin

[Ondro Mihályi]

Hi Kevin,

Copying the history is not very complicated, I did it in 10 minutes and simply rebased all commits from the bom repo onto the microprofile repo: https://github.com/eclipse/microprofile/pull/25

A problem is that the PR is failing Eclipse IP checks because it's raised by me but contains commits from various other people...
I think we can safely ignore the check and merge because the code is already within Eclipse. If not, then I'd just copy the content and move forward.

--Ondro

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d334259e-e0c8-472f-8475-9f646c157c78%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 "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/DAemBIWP9mI/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/3eb3ac0f-be6c-4651-a1b1-04e464d369ae%40googlegroups.com.

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

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

--
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/DAemBIWP9mI/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/51955253-9747-404d-9d09-7b7dc0679190%40googlegroups.com.

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

[Kevin Sutter]

Thanks, Ondro!  I will review your PR shortly...  I agree that we can safely ignore those IP checks for this exercise.  I may want to pick your brain a bit with the process here, but I'll look to see what you did first.  Thanks again.

-- 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/59246033-d422-4274-9c4e-7ed50f6ea47c%40googlegroups.com.

[Kevin Sutter]

Looking for some guidance...

I recently merged in Ondro's PR for moving the MicroProfile spec documents from the microprofile-bom repo to the microprofile repo.  The intent of this move was to keep the history of the respective documents.  The commit content looked like all of the history was intact.  But, after the merge, the only commit history I see is the current commit that Ondro and I did...  In a private email exchange with Ondro, he's wondering whether the complete history will become visible when we move the spec documents to their original location (we currently have them in a temporary microprofile-spec directory.  We're not sure.

Does anybody have any history with this type of move?  We're trying to get this in shape for the upcoming MP 1.4/2.0 releases.  Thanks for your help!

-- Kevin

[Emily Jiang]

I had a look at https://github.com/eclipse/microprofile/commits/master

It has the history. Is this what you meant?

Thanks
Emily

[Kevin Sutter]

Thank you, Emily.  This must be what Ondro was referring to.  I was just looking at the individual file histories and those don't show up.  The overall history does show up as your link demonstrates.  As Ondro suggested, maybe the individual file histories will start showing up when the directory structures match up...  I'll get on that PR right now and see if we can make this workable... 

Thanks!
Kevin

[Ondro Mihályi]

Hi Kevin,

Yes, that's what I meant. Right now, the commits are in the global commit log but don't appear for individual files in github because they were renamed. However, github shows the history if you use the blame feature. If you execute git log --follow, you will see the complete history of a individual file even across renames. Try:

git log --follow microprofile-spec/pom.xml

If we move the files back to root, I believe that github will show the complete history because the path will be the same as before.

--Ondro

[Werner Keil]

AFAIS this PR https://github.com/eclipse/microprofile/pull/25/files contains the POM formerly known as BOM, but not a new BOM that serves the purpose like a few Jakarta EE projects also started using (e.g. https://github.com/eclipse-ee4j/grizzly/tree/master/bom)

Is the idea to keep that "Parent POM" or whatever to call it under the "microprofile" repository so "microprofile-bom" may host a true BOM along the lines of Grizzly, Spring, JBoss, etc.?

If that is the intention, it seems this PR would be a good first step.

Werner

[Kevin Sutter]

Yes, Werner, the ultimate goal is to allow microprofile-bom to develop a "real" BOM like JBoss has defined...

--  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/95388c3f-2d79-4bee-b020-1d18c81bc51d%40googlegroups.com.

[Sebastian Daschner]

Are there any updates on this? IMO a BOM (as in dependencyManagement, in sync with the main MicroProfile artifact) still adds value to keep artifacts in sync for whatever your runtime supports (e.g. MicroProfile 2.0).

Cheers,
Sebastian 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/95388c3f-2d79-4bee-b020-1d18c81bc51d%40googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "Eclipse 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8ermhnc4MDkz48dH7T%3D-UPLF5itjwSr%3Df7Pf8nGro9LXJ5A%40mail.gmail.com.

[Kevin Sutter]

Sebastian, I agree that a BOM is still useful.  I just haven't had the cycles to do the necessary cleanup and work...  Feel free to offer your expertise, if you have some time!  :-)

Thanks,

Kevin

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAK1U5v-NwnyLCcLhsjVUfpgNRwisko2J5g_RD19LnBCD80T31g%40mail.gmail.com.

[Sebastian Daschner]

Sure, happy to help. I've created a first draft of a BOM using MP 2.1 and PR'ed it: https://github.com/eclipse/microprofile/pull/78

Cheers,
Sebastian 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CABH8er%3DrZeHt_qqaCBv7%2BQA6fn%3D6oZoP_UknRRPy5cii4EKdBQ%40mail.gmail.com.

[Erik Mattheis]

I found the Github repo before I found this discussion, but after skimming through some earlier posts, I'm still not clear where this initiative stands. It seems to me that the main pom in https://github.com/eclipse/microprofile/ is fine with a little tweaking. I've submitted the following PR to introduce a <dependencyManagement> section allowing the use of the pom in an import-only capacity.

https://github.com/eclipse/microprofile/pull/84

I find that I often have modules that depend on a subset of MicroProfile and I'd like to track the MicroProfile versions without declaring a dependency on the entire stack. I believe this change would make that easy to manage without breaking any existing usage of the pom.

-- 

Erik

[Werner Keil]

The BOM is dead, the repository should be archived instead of just claiming it's deprecated in the repo.

Your proposal looks interesting, similar to e.g. what we did with the JSR 354 RI after its modularization. 

Not merging here but it seems like a good approach.

Werner

[Kevin Sutter]

Werner,

This whole discussion indicates that the BOM is not dead...  :-)  It continues to raise it's ugly head...

FYI, the BOM proposal by Erik via PR #84 is being considered for inclusion in MP 2.2...  I'm about to kick off an RC1 for MP 2.2 and I'm thinking about including this BOM structure in the pom.xml.  It does not seem to affect current usage of the pom.xml, but it provides more BOM-like flexibility.  Comments here or on the issue would be appreciated. 

Thanks,

Kevin

[Werner Keil]

The old repository should be archived if it's no longer active. 

Those proposed changes from Erik, I think they go in a better direction for that parent/bom or whatever the POM is now supposed to be...

Werner

[Ondro Mihályi]

+1

I support the idea of improving the current API artifact to seamlessly also become a BOM artifact. I gave my reasons in the PR.

I think that the BOM repo should be archived.

--Ondro

Dňa pi 1. 2. 2019, 20:09 Werner Keil <werne...@gmail.com> napísal(a):

--

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/DAemBIWP9mI/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/7c09814e-d75a-4a08-b3a3-68b10f2ff5a6%40googlegroups.com.

[Kevin Sutter]

Okay, thanks for all of the input!  After careful consideration, I'm going to go ahead and take this PR #84 in and then cut an RC1 for MP 2.2.  Please take this RC through its paces to ensure no issues with current usage.  Thank you!

We will also discuss at tomorrow's hangout.

-- Kevin

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

[Roberto Cortez]

Hi, 

I was wondering about something, and I’m sorry if this was discussed before, just now aware of it.

Was there any consideration to release an artifact version which includes all API’s in a single jar? Like we have on the EE world?

Cheers,

Roberto

You received this message because you are subscribed to the Google Groups "Eclipse 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/18047d97-fecb-49eb-802d-893e3219b3b6%40googlegroups.com.

[Werner Keil]

I doubt that will ever make sense, MicroProfile is far too diverse and some features evolve more quickly while others don't or are almost dead.

While outside the JDK the JMOD format seems less relevant, it shows that with 70 different files there's also modularity compared to the big old rt.jar. Similar for Jakarta EE, whether as JARs or different, we also won't see a monolithic Uber JAR there any more and for MicroProfile it seems even more important to be modular.

Cheers,

Werner

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/7c09814e-d75a-4a08-b3a3-68b10f2ff5a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roberto Cortez]

You always had the "modular" piece. You could use each spec api jar on its own. Same case here, since each spec has its own API jar, you can pick which ones you want to use. On the other hand, if you want to include everything and just forget you could include an uber jar with all the specs.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b49d7457-ed3c-444c-a532-13b6e024b9c7%40googlegroups.com.

[Rudy De Busscher]

Hi Roberto,

>Was there any consideration to release an artifact version which includes all API’s in a single jar? 

Is this really needed, a jar with all API? you can just do for example

    <dependency>

      <groupId>org.eclipse.microprofile</groupId>

      <artifactId>microprofile</artifactId>

      <version>2.0.1</version>

      <type>pom</type>

      <scope>provided</scope>

    </dependency>

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/7c09814e-d75a-4a08-b3a3-68b10f2ff5a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roberto Cortez]

I know,

I was just wondering, because with the continue grow of MP (and there is a thread talking about it) we now have 8 different jars being added. I guess it is more of a personal opinion, but I’m starting to find it annoying when looking into classpaths or maven dependency plugin :) Usually these are not the things you are looking for, and they are just adding noise.

Cheers,

Roberto

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4cd91fb2-3851-4ecb-80aa-368802f30191%40googlegroups.com.