Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Stéphane Épardaud
    @FroMage
    yes, it can wait for the next release, as it's only adding a method
    Michael Musgrove
    @mmusgrov
    I would like to ask for some advice on filling out a CQ for MP-LRA. There is a question about who the authors are but these MP specs are community efforts, what did you add for this section. The questionare also asks for a contribution url, should I use the LRA project github page for that?
    Michael Musgrove
    @mmusgrov
    May I also ask why your CQ is in the state withdrawn (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20189)
    @njr-11 why was the CQ for MP-CP withdrawn?
    Nathan Rauh
    @njr-11
    @mmusgrov the CQs that I opened (especially the first few sets of them) are bad examples because I wasn't following the process correctly. It turns out the CQs are actually for third-party artifacts that we depend on: either for building our spec packages or the TCK. For MP Context Propagation, this included things like CDI, JTA or TestNG - all of which are used in the TCK. The correct process, which I eventually learned after several tries, is the following (several important links are available from this page, https://wiki.eclipse.org/MicroProfile/3rdPartyDependencyProcess). First, check the chart to see if MicroProfile in general already has a CQ for the product & exact level that you are using. If so, there is no action needed for that dependency. Otherwise, you need to create a CQ for your project to use that dependency. On the CQ page, you are actually submitting a CQ to use third-party software, and the optimal approach is to 'piggyback' on one which Eclipse has already approved for a different project (not MicroProfile) because these approvals tend to go through in a day, whereas trying to submit an entirely new one was taking over a week. One option that you might have is adjusting the version of dependencies in your pom to match what is already approved to make the process easier.
    Here is the list of CQs that I submitted correctly and got approved,
    https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20275
    https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20276
    https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20277
    plus one that Kevin Sutter kindly submitted on behalf of MP Context Propagation to demonstrate the correct process,
    https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20274
    Michael Musgrove
    @mmusgrov
    Thanks for that, very useful. Once I have found an existing CQ for one of my dependencies how do I create a piggyback CQ . The form for creating a CQ does not include a box for piggybacking: https://projects.eclipse.org/projects/technology.microprofile/cq/create/intro
    Nathan Rauh
    @njr-11
    After selecting to create a CQ for a third-party dependency, on the next page under "Name and Version of the Library" start typing the dependency name, such as CDI, and it will show a list of existing CQs at the various levels which have already been approved for other Eclipse projects. By selecting an existing version, you are implicitly requesting to piggyback on that approval. (I tried to take the lowest CQ number with the version that I wanted, so as to piggyback on the original - not sure if that matters)
    Michael Musgrove
    @mmusgrov
    Great, thanks
    Well my first attempt to create a CQ for javax.ws.rs-api:2.0.1 produced the error The website encountered an unexpected error. Please try again later.
    I'll try that again ..
    Michael Musgrove
    @mmusgrov
    Yey, I have my CQ, it's easy when one knows how ;) thanks
    Nathan Rauh
    @njr-11
    Now that we've both misinterpreted the process and then figured out how to do it right, it seems like it would be a good idea to update the wiki page for others with some additional clarifying instructions
    Nathan Rauh
    @njr-11
    @manovotn @FroMage Now that we have reached July, have you found any issues/feedback with MP Context Propagation in Quarkus that would prevent the 1.0 release of the spec? Let me know if it's okay to proceed with the release.
    Stéphane Épardaud
    @FroMage
    No, nothing so far, so we can proceed with 1.0.
    Nathan Rauh
    @njr-11

    release 1.0 binaries are available on Maven here,

    <dependency>
    <groupId>org.eclipse.microprofile.context-propagation</groupId>
    <artifactId>microprofile-context-propagation-api</artifactId>
    <version>1.0</version>
</dependency>

    I'm working on getting through the remaining process for announcing the release and so forth

    Matej Novotny
    @manovotn
    Nice! Thanks for handling that
    Stéphane Épardaud
    @FroMage
    Cool, thanks
    Michael Musgrove
    @mmusgrov
    @njr-11 or @FroMage May I ask how you obtained permisions to promote staged artefacts on oss.sonatype.org
    Nathan Rauh
    @njr-11
    @mmusgrov the instructions are on this page, under "If you are a committer and don't have access..."
    https://wiki.eclipse.org/MicroProfile/Maven
    Michael Musgrove
    @mmusgrov
    Thanks for that
    Nathan Rauh
    @njr-11
    With the 1.0 version of the spec completed and less attendees at the weekly meetings, what does everyone think about reducing these meeting occurrences, and what would be best? Once per month? Once every 3 weeks? Twice per month?
    Matej Novotny
    @manovotn
    I'd say once a month is reasonable, there doesn't seem to much to discuss anyway. We could always revert to a more frequent schedule.
    Stéphane Épardaud
    @FroMage
    yeah, once a month is more than enough
    Nathan Rauh
    @njr-11
    Thanks, I'll look into updating the calendar to limit to once per month
    Nathan Rauh
    @njr-11
    If I've edited the calendar entry correctly, then the recurring call should now be limited to the second Thursday of every month. The one exception being that I left this week's meeting just in case anyone didn't see this chat, so that I can let them know when they call in.
    Stéphane Épardaud
    @FroMage
    It appears that testng support for Eclipse is dead
    it's not been updated in the marketplace for the latest Eclipse release (from early this year)
    and the manual install site is 404
    @njr-11 IIRC we moved to testng to get in line with other MP specs, right?
    frankly that surprised me, because I thought testng died a decade ago, but I didn't really have much to stand on, besides "junit is moving a lot more today"
    but this lack of IDE support is really problematic
    if you would not mind going back to junit, I can send a mail to the MP mailing list discussing a move to junit
    Stéphane Épardaud
    @FroMage
    ok, my bad, the manual install site is working now, it probably was down when I hit it
    it's still pretty annoying to use testng, though :(
    Nathan Rauh
    @njr-11
    @FroMage sorry I was out of the office for a week and wasn't able to keep up on email/chats. If I understand correctly, it sounds like the immediate issue with testng was resolved. As to whether we can switch back to junit, I think that's a question of alignment with the other MicroProfile specifications. If all of the others are using testng, then we need to do the same for consistency, but if the others are varied between testng/junit, then we should be fine switching.
    Stéphane Épardaud
    @FroMage
    Yeah, I wasn't suggesting switching alone, but raising the question for all MP specs, but only if you don't mind, otherwise there's not much point :)
    Nathan Rauh
    @njr-11
    That sounds good - raise the question for MP as a whole. I don't have any objections to switching
    Stéphane Épardaud
    @FroMage
    ok thanks
    Nathan Rauh
    @njr-11
    I've added #174 to update our version number to 1.1 so that it will be clear that new snapshot builds correspond to post-1.0 release. Could someone review it?
    Stéphane Épardaud
    @FroMage
    Done
    Matej Novotny
    @manovotn

    So, while trying to run the TCK with Quarkus I came across this one bit in tests - https://github.com/eclipse/microprofile-context-propagation/blob/master/tck/src/main/java/org/eclipse/microprofile/context/tck/ThreadContextTest.java#L155-L160

    This gives me crashes with IllegalAccessException probably because of class loader black magic that quarkus uses to execute Arquillian.
    Nonetheless, I find this approach very awkward at best, does anyone happen to remember why it's there?
    We could simply call (for instance) CDI.current().select(UserTransaction.class).isResolvable()

    @njr-11 @FroMage @mmusgrov ^^
    Stéphane Épardaud
    @FroMage
    well, that would make it depend on CDI, but apparently it already does, though it's not used
    it was added in fbe0b27eda0a14d54053352dc053f986272c8917
    for config, which was later removed but not the dependency
    so the pom depends on cdi but not the code
    a bit unfortunate
    eclipse/microprofile-context-propagation@fbe0b27
    Nathan Rauh
    @njr-11
    I believe someone raised a requirement at one point for MP Context Propagation to be usable regardless of whether CDI was available. So even back when we had the config annotations (@ManagedExecutorConfig) the TCK tests went out of their way to ensure that an implementation could pass when CDI was not available.