From rsvoboda at redhat.com Wed Sep 6 08:42:21 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Wed, 6 Sep 2017 08:42:21 -0400 (EDT) Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <224545687.9065519.1504697837274.JavaMail.zimbra@redhat.com> Message-ID: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> Hi. https://developer.jboss.org/thread/224262 announced availability of WildFly nightly builds. Current status is that you must know the URL based on current version in master At this moment it is https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-11.0.0.Final-SNAPSHOT.zip, root dir of the zip is wildfly-11.0.0.Final-SNAPSHOT '11.0.0.Final-SNAPSHOT' is the changing part and when you want to consume nightly build in CI (e.g. Travis) you end up doing unnecessary changes to .travis.yml (Alpha1-SNAPSHOT ==> Beta1-SNAPSHOT ==> Final-SNAPSHOT) when PRs fail because of unavailable nightly bits I would like to make automated consumption of WildFly nightly builds easier Proposal 1 - expose latest bits under the same URL + keep the same root dir name URL: https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-latest-SNAPSHOT.zip root dir of the zip: wildfly-latest-SNAPSHOT Automation would be prepared just once and "work forever". Proposal 2 - keep current zip & root dir name + add txt file with version information introduce https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/version.txt Currently it would contain '11.0.0.Final-SNAPSHOT' Example to get version: mvn help:evaluate -Dexpression=project.version | grep -v "^\[" Automation could consume content of version.txt and construct the download URL + root dir name VERSION=`curl https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/version.txt` https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-${VERSION}.zip root dir of the zip is wildfly-${VERSION} WDYT? Regards. Rostislav From jcacek at redhat.com Wed Sep 6 10:09:45 2017 From: jcacek at redhat.com (Josef Cacek) Date: Wed, 6 Sep 2017 10:09:45 -0400 (EDT) Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> Message-ID: <86615141.3714362.1504706985566.JavaMail.zimbra@redhat.com> You can also use a workaround through artifacts.zip. We use something like this in our automation: wget --user=guest --password=guest https://ci.wildfly.org/httpAuth/repository/downloadAll/WF_Nightly/.lastSuccessful/artifacts.zip unzip -q artifacts.zip export WILDFLY_DIST_ZIP=$(ls wildfly-*-SNAPSHOT.zip) unzip -q $WILDFLY_DIST_ZIP export WILDFLY_HOME=`pwd`/${WILDFLY_DIST_ZIP%.zip} Regards, -- Josef ----- Original Message ----- > From: "Rostislav Svoboda" > To: "WildFly Dev" > Sent: Wednesday, September 6, 2017 2:42:21 PM > Subject: [wildfly-dev] WildFly nightly builds > > Hi. > > https://developer.jboss.org/thread/224262 announced availability of WildFly > nightly builds. > > Current status is that you must know the URL based on current version in > master > At this moment it is > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-11.0.0.Final-SNAPSHOT.zip, > root dir of the zip is wildfly-11.0.0.Final-SNAPSHOT > > '11.0.0.Final-SNAPSHOT' is the changing part and when you want to consume > nightly build in CI (e.g. Travis) you end up doing unnecessary changes to > .travis.yml (Alpha1-SNAPSHOT ==> Beta1-SNAPSHOT ==> Final-SNAPSHOT) when PRs > fail because of unavailable nightly bits > > I would like to make automated consumption of WildFly nightly builds easier > > Proposal 1 - expose latest bits under the same URL + keep the same root dir > name > URL: > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-latest-SNAPSHOT.zip > root dir of the zip: wildfly-latest-SNAPSHOT > > Automation would be prepared just once and "work forever". > > > Proposal 2 - keep current zip & root dir name + add txt file with version > information > introduce > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/version.txt > Currently it would contain '11.0.0.Final-SNAPSHOT' > Example to get version: mvn help:evaluate -Dexpression=project.version | > grep -v "^\[" > > Automation could consume content of version.txt and construct the download > URL + root dir name > VERSION=`curl > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/version.txt` > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-${VERSION}.zip > root dir of the zip is wildfly-${VERSION} > > > WDYT? > > Regards. > Rostislav > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jason.greene at redhat.com Wed Sep 6 15:02:44 2017 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 6 Sep 2017 14:02:44 -0500 Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> Message-ID: I like Proposal #1. > On Sep 6, 2017, at 7:42 AM, Rostislav Svoboda wrote: > > Hi. > > https://developer.jboss.org/thread/224262 announced availability of WildFly nightly builds. > > Current status is that you must know the URL based on current version in master > At this moment it is https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-11.0.0.Final-SNAPSHOT.zip, root dir of the zip is wildfly-11.0.0.Final-SNAPSHOT > > '11.0.0.Final-SNAPSHOT' is the changing part and when you want to consume nightly build in CI (e.g. Travis) you end up doing unnecessary changes to .travis.yml (Alpha1-SNAPSHOT ==> Beta1-SNAPSHOT ==> Final-SNAPSHOT) when PRs fail because of unavailable nightly bits > > I would like to make automated consumption of WildFly nightly builds easier > > Proposal 1 - expose latest bits under the same URL + keep the same root dir name > URL: https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-latest-SNAPSHOT.zip > root dir of the zip: wildfly-latest-SNAPSHOT > > Automation would be prepared just once and "work forever". > > > Proposal 2 - keep current zip & root dir name + add txt file with version information > introduce https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/version.txt > Currently it would contain '11.0.0.Final-SNAPSHOT' > Example to get version: mvn help:evaluate -Dexpression=project.version | grep -v "^\[" > > Automation could consume content of version.txt and construct the download URL + root dir name > VERSION=`curl https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/version.txt` > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-${VERSION}.zip > root dir of the zip is wildfly-${VERSION} > > > WDYT? > > Regards. > Rostislav > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene Chief Architect, JBoss EAP Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170906/8aca3e4e/attachment.html From ehugonne at redhat.com Thu Sep 7 03:57:07 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Thu, 7 Sep 2017 09:57:07 +0200 Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> Message-ID: <9614e267-01b1-e608-77cd-b025da51f719@redhat.com> Hi, Why not jut have a root dir named latest and put the date (aka resolve the snapshot) in the zip name as I think the date of production is an important information for a nightly build thus it should be part of the artifact name: https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest/wildfly-nightly-201709070001.zip Maybe we could also put a "symlink" to it when upload is finished like https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest/wildfly-nightly-latest.zip Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170907/5c9b7bfa/attachment.bin From rory.odonnell at oracle.com Thu Sep 7 05:37:16 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 7 Sep 2017 10:37:16 +0100 Subject: [wildfly-dev] Moving Java Forward Faster Message-ID: <91a3cbe7-db72-869a-bd88-e04cbf4b152c@oracle.com> Hi Jason/Tomaz, Oracle is proposing a rapid release model for Java SE going-forward. The high points are highlighted below, details of the changes can be found on Mark Reinhold?s blog [1] , OpenJDK discussion email list [2]. Under the proposed release model, after JDK 9, we will adopt a strict, time-based model with a new major release every six months, update releases every quarter, and a long-term support release every three years. The new JDK Project will run a bit differently than the past "JDK $N" Projects: - The main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished. The main line will be Feature Complete [3] at all times. - We'll continue to use the JEP Process [4] for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration. The JDK Updates Project will run in much the same way as the past "JDK $N" Updates Projects, though update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Related to this proposal, we intend to make a few changes in what we do: - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to make it easier for developers to deploy Java applications to cloud environments. We'll initially publish OpenJDK builds for Linux/x64, followed later by builds for macOS/x64 and Windows/x64. - We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" [6] such as Java Flight Recorder and Mission Control [7], under a click-through binary-code license [8]. Oracle will continue to offer paid support for these builds. - After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable. - Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK. Questions , comments, feedback to OpenJDK discuss mailing list [2] Rgds,Rory [1]https://mreinhold.org/blog/forward-faster [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [4]http://openjdk.java.net/jeps/0 [5]http://openjdk.java.net/legal/gplv2+ce.html [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170907/622c6d3e/attachment.html From tomaz.cerar at gmail.com Thu Sep 7 06:08:46 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 7 Sep 2017 12:08:46 +0200 Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <9614e267-01b1-e608-77cd-b025da51f719@redhat.com> References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> <9614e267-01b1-e608-77cd-b025da51f719@redhat.com> Message-ID: Whatever we decide to do, we need to update WildFly build to do so, not just CI job. probably best thing to add some new profile to dist module that would provide what we need. On Thu, Sep 7, 2017 at 9:57 AM, Emmanuel Hugonnet wrote: > Hi, > > Why not jut have a root dir named latest and put the date (aka resolve the > snapshot) in the zip name as I think the date of production is an > important information for a nightly build thus it should be part of the > artifact name: > > https://ci.wildfly.org/guestAuth/repository/download/ > WF_Nightly/latest/wildfly-nightly-201709070001.zip > > Maybe we could also put a "symlink" to it when upload is finished like > https://ci.wildfly.org/guestAuth/repository/download/ > WF_Nightly/latest/wildfly-nightly-latest.zip > > Emmanuel > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170907/0e7e9336/attachment-0001.html From rsvoboda at redhat.com Thu Sep 7 08:23:32 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Thu, 7 Sep 2017 08:23:32 -0400 (EDT) Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> <9614e267-01b1-e608-77cd-b025da51f719@redhat.com> Message-ID: <209052620.10257031.1504787012248.JavaMail.zimbra@redhat.com> Hi. I prepared https://github.com/rsvoboda/wildfly/commit/7c48c50f8b054c4f7e06a78de6bea7f5292171eb to fix dist module so it can leverage already existing 'jboss.as.release.version' property. mvn clean install -DskipTests -Denforcer.skip=true -Dcheckstyle.skip=true -Djboss.as.release.version=latest -Prelease ... ls dist/target | grep wildfly wildfly-latest wildfly-latest.jar wildfly-latest-src.tar.gz wildfly-latest-src.zip wildfly-latest.tar.gz wildfly-latest.zip So WF_Nightly job would just use '-Djboss.as.release.version=latest' and we would have Option #1 solved. Can I proceed with PR? Is it something I should propose also for product branch ? Rostislav ----- Original Message ----- > Whatever we decide to do, we need to update WildFly build to do so, not just > CI job. > > probably best thing to add some new profile to dist module that would provide > what we need. > > On Thu, Sep 7, 2017 at 9:57 AM, Emmanuel Hugonnet < ehugonne at redhat.com > > wrote: > > > Hi, > > Why not jut have a root dir named latest and put the date (aka resolve the > snapshot) in the zip name as I think the date of production is an > important information for a nightly build thus it should be part of the > artifact name: > > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest/wildfly-nightly-201709070001.zip > > Maybe we could also put a "symlink" to it when upload is finished like > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest/wildfly-nightly-latest.zip > > Emmanuel > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Thu Sep 7 09:27:44 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 7 Sep 2017 15:27:44 +0200 Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <86615141.3714362.1504706985566.JavaMail.zimbra@redhat.com> References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> <86615141.3714362.1504706985566.JavaMail.zimbra@redhat.com> Message-ID: Yeah we can always bash around it, on our CI or when consuming it, but that is not a clean solution in any case. Having build updated to easier allow for what we need is a way to go. -- tomaz On Wed, Sep 6, 2017 at 4:09 PM, Josef Cacek wrote: > You can also use a workaround through artifacts.zip. We use something like > this in our automation: > > wget --user=guest --password=guest https://ci.wildfly.org/ > httpAuth/repository/downloadAll/WF_Nightly/.lastSuccessful/artifacts.zip > unzip -q artifacts.zip > export WILDFLY_DIST_ZIP=$(ls wildfly-*-SNAPSHOT.zip) > unzip -q $WILDFLY_DIST_ZIP > export WILDFLY_HOME=`pwd`/${WILDFLY_DIST_ZIP%.zip} > > > Regards, > > -- Josef > > ----- Original Message ----- > > From: "Rostislav Svoboda" > > To: "WildFly Dev" > > Sent: Wednesday, September 6, 2017 2:42:21 PM > > Subject: [wildfly-dev] WildFly nightly builds > > > > Hi. > > > > https://developer.jboss.org/thread/224262 announced availability of > WildFly > > nightly builds. > > > > Current status is that you must know the URL based on current version in > > master > > At this moment it is > > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest. > lastFinished/wildfly-11.0.0.Final-SNAPSHOT.zip, > > root dir of the zip is wildfly-11.0.0.Final-SNAPSHOT > > > > '11.0.0.Final-SNAPSHOT' is the changing part and when you want to consume > > nightly build in CI (e.g. Travis) you end up doing unnecessary changes to > > .travis.yml (Alpha1-SNAPSHOT ==> Beta1-SNAPSHOT ==> Final-SNAPSHOT) when > PRs > > fail because of unavailable nightly bits > > > > I would like to make automated consumption of WildFly nightly builds > easier > > > > Proposal 1 - expose latest bits under the same URL + keep the same root > dir > > name > > URL: > > https://ci.wildfly.org/guestAuth/repository/download/ > WF_Nightly/latest.lastFinished/wildfly-latest-SNAPSHOT.zip > > root dir of the zip: wildfly-latest-SNAPSHOT > > > > Automation would be prepared just once and "work forever". > > > > > > Proposal 2 - keep current zip & root dir name + add txt file with version > > information > > introduce > > https://ci.wildfly.org/guestAuth/repository/download/ > WF_Nightly/latest.lastFinished/version.txt > > Currently it would contain '11.0.0.Final-SNAPSHOT' > > Example to get version: mvn help:evaluate > -Dexpression=project.version | > > grep -v "^\[" > > > > Automation could consume content of version.txt and construct the > download > > URL + root dir name > > VERSION=`curl > > https://ci.wildfly.org/guestAuth/repository/download/ > WF_Nightly/latest.lastFinished/version.txt` > > https://ci.wildfly.org/guestAuth/repository/download/ > WF_Nightly/latest.lastFinished/wildfly-${VERSION}.zip > > root dir of the zip is wildfly-${VERSION} > > > > > > WDYT? > > > > Regards. > > Rostislav > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170907/8b43da6a/attachment.html From bmcwhirt at redhat.com Thu Sep 7 10:54:45 2017 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Thu, 7 Sep 2017 10:54:45 -0400 Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> <86615141.3714362.1504706985566.JavaMail.zimbra@redhat.com> Message-ID: I haven?t followed entirely, but back in the day of TorqueBox, we?d use a normal CI build, without modifying the pom.xml or other bits. All we?d do is prior to building the -SNAPSHOT version, we?d mvn versions:set -DnewVersion=x.y.z.incremental.$BUILD_NO e.g. mvn versions:set -DnewVersion=11.0.0.incremental.$BUILD_NO We also actually did that to WildFly proper, since TorqueBox built against WF. This allowed us to build against a non-SNAPSHOT release of WF without having to wait for you guys to produce a release, because -SNAPSHOTs are terrible and WF 8 took quite a while to arrive. I called them ?incremental? because they happened many times a day, and thus not ?nightly? builds in our case. Using the CI-provided builder number ensured they were sequential, and using the base version number helped know what the build roughly was. -Bob On Thu, Sep 7, 2017 at 9:27 AM, Toma? Cerar wrote: > Yeah we can always bash around it, on our CI or when consuming it, > but that is not a clean solution in any case. > > Having build updated to easier allow for what we need is a way to go. > > -- > tomaz > > On Wed, Sep 6, 2017 at 4:09 PM, Josef Cacek wrote: > >> You can also use a workaround through artifacts.zip. We use something >> like this in our automation: >> >> wget --user=guest --password=guest https://ci.wildfly.org/httpAut >> h/repository/downloadAll/WF_Nightly/.lastSuccessful/artifacts.zip >> unzip -q artifacts.zip >> export WILDFLY_DIST_ZIP=$(ls wildfly-*-SNAPSHOT.zip) >> unzip -q $WILDFLY_DIST_ZIP >> export WILDFLY_HOME=`pwd`/${WILDFLY_DIST_ZIP%.zip} >> >> >> Regards, >> >> -- Josef >> >> ----- Original Message ----- >> > From: "Rostislav Svoboda" >> > To: "WildFly Dev" >> > Sent: Wednesday, September 6, 2017 2:42:21 PM >> > Subject: [wildfly-dev] WildFly nightly builds >> > >> > Hi. >> > >> > https://developer.jboss.org/thread/224262 announced availability of >> WildFly >> > nightly builds. >> > >> > Current status is that you must know the URL based on current version in >> > master >> > At this moment it is >> > https://ci.wildfly.org/guestAuth/repository/download/WF_ >> Nightly/latest.lastFinished/wildfly-11.0.0.Final-SNAPSHOT.zip, >> > root dir of the zip is wildfly-11.0.0.Final-SNAPSHOT >> > >> > '11.0.0.Final-SNAPSHOT' is the changing part and when you want to >> consume >> > nightly build in CI (e.g. Travis) you end up doing unnecessary changes >> to >> > .travis.yml (Alpha1-SNAPSHOT ==> Beta1-SNAPSHOT ==> Final-SNAPSHOT) >> when PRs >> > fail because of unavailable nightly bits >> > >> > I would like to make automated consumption of WildFly nightly builds >> easier >> > >> > Proposal 1 - expose latest bits under the same URL + keep the same root >> dir >> > name >> > URL: >> > https://ci.wildfly.org/guestAuth/repository/download/WF_ >> Nightly/latest.lastFinished/wildfly-latest-SNAPSHOT.zip >> > root dir of the zip: wildfly-latest-SNAPSHOT >> > >> > Automation would be prepared just once and "work forever". >> > >> > >> > Proposal 2 - keep current zip & root dir name + add txt file with >> version >> > information >> > introduce >> > https://ci.wildfly.org/guestAuth/repository/download/WF_ >> Nightly/latest.lastFinished/version.txt >> > Currently it would contain '11.0.0.Final-SNAPSHOT' >> > Example to get version: mvn help:evaluate >> -Dexpression=project.version | >> > grep -v "^\[" >> > >> > Automation could consume content of version.txt and construct the >> download >> > URL + root dir name >> > VERSION=`curl >> > https://ci.wildfly.org/guestAuth/repository/download/WF_ >> Nightly/latest.lastFinished/version.txt` >> >> > https://ci.wildfly.org/guestAuth/repository/download/WF_ >> Nightly/latest.lastFinished/wildfly-${VERSION}.zip >> > root dir of the zip is wildfly-${VERSION} >> > >> > >> > WDYT? >> > >> > Regards. >> > Rostislav >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170907/d0199522/attachment-0001.html From rsvoboda at redhat.com Fri Sep 8 02:35:45 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Fri, 8 Sep 2017 02:35:45 -0400 (EDT) Subject: [wildfly-dev] WildFly nightly builds In-Reply-To: <209052620.10257031.1504787012248.JavaMail.zimbra@redhat.com> References: <818800731.9183479.1504701741440.JavaMail.zimbra@redhat.com> <9614e267-01b1-e608-77cd-b025da51f719@redhat.com> <209052620.10257031.1504787012248.JavaMail.zimbra@redhat.com> Message-ID: <1429533775.10651126.1504852545690.JavaMail.zimbra@redhat.com> Hi. PR: https://github.com/wildfly/wildfly/pull/10487 I adjusted also servlet-dist module to be in sync with dist module and to make TS pass. Rostislav ----- Original Message ----- > Hi. > > I prepared > https://github.com/rsvoboda/wildfly/commit/7c48c50f8b054c4f7e06a78de6bea7f5292171eb > to fix dist module so it can leverage already existing > 'jboss.as.release.version' property. > > mvn clean install -DskipTests -Denforcer.skip=true -Dcheckstyle.skip=true > -Djboss.as.release.version=latest -Prelease > ... > ls dist/target | grep wildfly > wildfly-latest > wildfly-latest.jar > wildfly-latest-src.tar.gz > wildfly-latest-src.zip > wildfly-latest.tar.gz > wildfly-latest.zip > > So WF_Nightly job would just use '-Djboss.as.release.version=latest' and we > would have Option #1 solved. > > > Can I proceed with PR? Is it something I should propose also for product > branch ? > > > Rostislav > > ----- Original Message ----- > > Whatever we decide to do, we need to update WildFly build to do so, not > > just > > CI job. > > > > probably best thing to add some new profile to dist module that would > > provide > > what we need. > > > > On Thu, Sep 7, 2017 at 9:57 AM, Emmanuel Hugonnet < ehugonne at redhat.com > > > wrote: > > > > > > Hi, > > > > Why not jut have a root dir named latest and put the date (aka resolve the > > snapshot) in the zip name as I think the date of production is an > > important information for a nightly build thus it should be part of the > > artifact name: > > > > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest/wildfly-nightly-201709070001.zip > > > > Maybe we could also put a "symlink" to it when upload is finished like > > https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest/wildfly-nightly-latest.zip > > > > Emmanuel > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jai.forums2013 at gmail.com Tue Sep 12 01:37:41 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 12 Sep 2017 11:07:41 +0530 Subject: [wildfly-dev] Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite? Message-ID: <30d3bcb2-5cbf-9d8d-4e56-cf60c5eb416c@gmail.com> I was working on a change and a testcase related to one of the JIRAs open in WFLY and happened to notice that we now have a testsuite/integration/legacy-ejb-client module. It looks like this module has testcases that are also part of testsuite/integration/basic - i.e. copy pasted. So we now have 2 copies of a testcase for example EJBClientAPIUsageTestCase. What's the guideline when dealing with these testcases? Should both these testcases be kept up-to-date with any changes to the behaviour of the server interaction with the remote client? The context of my question is this PR https://github.com/wildfly/wildfly/pull/10466 -Jaikiran From jason.greene at redhat.com Tue Sep 12 01:52:37 2017 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 12 Sep 2017 00:52:37 -0500 Subject: [wildfly-dev] Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite? In-Reply-To: <30d3bcb2-5cbf-9d8d-4e56-cf60c5eb416c@gmail.com> References: <30d3bcb2-5cbf-9d8d-4e56-cf60c5eb416c@gmail.com> Message-ID: <31689D79-FF9A-47CC-9E71-5532B46A97DF@redhat.com> Hi Jaikiran, You probably already noticed alot of this, but just to make sure everyone is on the same page the legacy ejb client is for the 3.x branch of the ejb client code based, and the current client is the 4.x branch. The 3.x branch is the same as the 2.x branch, but with updates to synchronize dependencies and integrate with elytron capabilities. So 3.x is intended to be 100% API compat with 2.x. 4.x on the other hand has dropped some elements of the API that no longer make sense and added new APIs. So 3.x is unlikely to be enhanced further, with just bug fixes, and all new work going into 4.x. Since most access patterns port without issue, we expect 3.x will have fairly low usage, and will one day be phased out. So basically the only reason to add test coverage with 3.x use (legacy-ejb-client) is if there is a bug that affects it, or a change was made that is likely to impact its operation. Since 4.x is protocol compat with 3.x though, changes on the 4.x server side do need to factor in 3.x client behavior. -Jason > On Sep 12, 2017, at 12:37 AM, Jaikiran Pai wrote: > > I was working on a change and a testcase related to one of the JIRAs > open in WFLY and happened to notice that we now have a > testsuite/integration/legacy-ejb-client module. It looks like this > module has testcases that are also part of testsuite/integration/basic - > i.e. copy pasted. So we now have 2 copies of a testcase for example > EJBClientAPIUsageTestCase. What's the guideline when dealing with these > testcases? Should both these testcases be kept up-to-date with any > changes to the behaviour of the server interaction with the remote > client? The context of my question is this PR > https://github.com/wildfly/wildfly/pull/10466 > > -Jaikiran > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene Chief Architect, JBoss EAP Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170912/7a26da4d/attachment.html From jai.forums2013 at gmail.com Tue Sep 12 02:14:06 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 12 Sep 2017 11:44:06 +0530 Subject: [wildfly-dev] Any guidelines on dealing with (duplicate) tests in legacy-ejb-client testsuite? In-Reply-To: <31689D79-FF9A-47CC-9E71-5532B46A97DF@redhat.com> References: <30d3bcb2-5cbf-9d8d-4e56-cf60c5eb416c@gmail.com> <31689D79-FF9A-47CC-9E71-5532B46A97DF@redhat.com> Message-ID: Thanks Jason, that answers my question. I'll rework/rethink that PR to account for the 3.x client behaviour. -Jaikiran On 12/09/17 11:22 AM, Jason Greene wrote: > Hi Jaikiran, > > You probably already noticed alot of this, but just to make sure > everyone is on the same page the legacy ejb client is for the 3.x > branch of the ejb client code based, and the current client is the 4.x > branch. The 3.x branch is the same as the 2.x branch, but with updates > to synchronize dependencies and integrate with elytron capabilities. > So 3.x is intended to be 100% API compat with 2.x. 4.x on the other > hand has dropped some elements of the API that no longer make sense > and added new APIs. So 3.x is unlikely to be enhanced further, with > just bug fixes, and all new work going into 4.x. Since most access > patterns port without issue, we expect 3.x will have fairly low usage, > and will one day be phased out. > > So basically the only reason to add test coverage with 3.x use > (legacy-ejb-client) is if there is a bug that affects it, or a change > was made that is likely to impact its operation. Since 4.x is protocol > compat with 3.x though, changes on the 4.x server side do need to > factor in 3.x client behavior. > > -Jason > >> On Sep 12, 2017, at 12:37 AM, Jaikiran Pai > > wrote: >> >> I was working on a change and a testcase related to one of the JIRAs >> open in WFLY and happened to notice that we now have a >> testsuite/integration/legacy-ejb-client module. It looks like this >> module has testcases that are also part of testsuite/integration/basic - >> i.e. copy pasted. So we now have 2 copies of a testcase for example >> EJBClientAPIUsageTestCase. What's the guideline when dealing with these >> testcases? Should both these testcases be kept up-to-date with any >> changes to the behaviour of the server interaction with the remote >> client? The context of my question is this PR >> https://github.com/wildfly/wildfly/pull/10466 >> >> -Jaikiran >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > Chief Architect, JBoss EAP > Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170912/c54124c3/attachment.html From brian.stansberry at redhat.com Tue Sep 12 14:00:42 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 12 Sep 2017 13:00:42 -0500 Subject: [wildfly-dev] Dependency info on component upgrade pull requests Message-ID: I'd like to see some info on WildFly and WildFly Core pull requests that upgrade components where the submitter *is not* the "exclusive owner" of the lib being upgraded. An "owner" of a component is the person recorded in WFLY or WFCORE as the lead of the JIRA component that tracks issues related to the functionality the lib's used for. An owner is "exclusive" if his or her JIRA component is the only relevant one. The info I'd like: 1) Information showing the the modules that depend on the updated lib. This is quite easy to get once you know the name of the module that includes the lib (and if you don't know that you probably shouldn't be submitting the PR.) $ git grep javax.json.api | grep module.xml core-feature-pack/src/main/resources/modules/system/layers/base/javax/json/api/main/module.xml: core-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/security/elytron-private/main/module.xml: Since this lib is in core, it may have uses in full so include that too: $ git grep javax.json.api | grep module.xml feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml: feature-pack/src/main/resources/modules/system/layers/base/org/apache/activemq/artemis/main/module.xml: feature-pack/src/main/resources/modules/system/layers/base/org/jboss/resteasy/resteasy-json-p-provider/main/module.xml: 2) An @ mention of the owners of the component identified above so they are aware of and can approve the change. If you don't know who these people are, skip this. But if you're someone who really should know this stuff, please learn it and include it. Owners, please respond to these mentions. I don't think asking for this stuff from the exclusive owner of a lib makes sense; they should know what they are doing and the cost of added paperwork exceeds any likely benefit. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170912/130342de/attachment-0001.html From tomaz.cerar at gmail.com Tue Sep 19 08:58:58 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 19 Sep 2017 14:58:58 +0200 Subject: [wildfly-dev] WildFly asciidoc based documentation Message-ID: Hey guys, TL;DR I've converted confluence docs asciidoc [1] [2] ones that will be part of WildFly codebase, take a look at them and let me know if there are any big issues. ---- full version: as most of you already know, I was working on moving our confluence based [1] documentation to asciidoc based one. result can be seen at [7] or rendered to html at [8] A good side effect of conversion is that now docs are also browsable directly on GitHub. For example [2] or [3] Currently I kept same structure as we had in confluence, which in practice means we have set of "guides" that than have lots of sub pages / includes that produce "big" guides. Currently such guides are: - Admin Guide - Developer Guide - Getting started guide - Getting Started Developing Applications Guide - High Availability Guide - Extending WildFly guide - JavaEE 7(6 actually) Tutorial - Elytron security guide - quickstarts - Testsuite Problem is that some of this guide as such make sense, but not all of them do. In some cases we have duplicated docs for same thing, in others we content in wrong segment. For example instead of having all subsystem reference docs under admin guide, some are under Developer Guide and some even under HA guide. Going forward we should "refactor" docs a bit, so we would end up with 3-4 high quality guides. We should also go trough all docs and remove/update the outdated content. Plan is also to have documentation now part of WildFly codebase. So when we would submit PR with new feature, it would also include documentation for it as well. Rendered docs can be build as part of our build / release process and can be rendered to different formats. for example default is HTML [5] or PDF [6] I've send experimental PR to show how docs would fit into WildFly build [4] Please take look at current docs and if you have any comments / suggestions what we can improve before merging it let me know. At this point I've not done much content-wise changes but just conversion + formatting ones. Content updates can come after this is merged. -- tomaz [1] https://docs.jboss.org/author/display/WFLY/Documentation [2] https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc [3] https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc [4] https://github.com/wildfly/wildfly/pull/10523 [5] https://ctomc.github.io/docs-playground/Admin_Guide.html [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf [7] https://github.com/ctomc/docs-playground [8] https://ctomc.github.io/docs-playground/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170919/78539e9b/attachment.html From rsvoboda at redhat.com Wed Sep 20 07:00:57 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Wed, 20 Sep 2017 07:00:57 -0400 (EDT) Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: References: Message-ID: <736426731.18748051.1505905257464.JavaMail.zimbra@redhat.com> Hi Tomaz. How would this change translate to product branch ? Would it also make sense to extract parts of documentation related to "Servlet-Only Distribution" provided on http://wildfly.org/downloads/ ? I think current documentation presumes full app server distribution. Maybe going further it would also make sense to compose docs via provisioning tool (https://github.com/aloubyansky/pm/) so users could have up to date documentation related to stuff they are using in their setup ... e.g. when they compose server just with undertow + resteasy + hibernate they wouldn't get documentation for clustering, soap webservices, messaging, ... The same could also happen for Quickstarts, have them provisioned via pm (or similar) tool based on the selected components/feature packs. Rostislav ----- Original Message ----- > Hey guys, > > TL;DR > I've converted confluence docs asciidoc [1] [2] ones that will be part of > WildFly codebase, > take a look at them and let me know if there are any big issues. > > > ---- > full version: > > as most of you already know, I was working on moving our confluence based [1] > documentation to asciidoc based one. > > result can be seen at [7] or rendered to html at [8] > > A good side effect of conversion is that now docs are also browsable directly > on GitHub. > For example [2] or [3] > > Currently I kept same structure as we had in confluence, which in practice > means > we have set of "guides" that than have lots of sub pages / includes that > produce "big" guides. > Currently such guides are: > - Admin Guide > - Developer Guide > - Getting started guide > - Getting Started Developing Applications Guide > - High Availability Guide > - Extending WildFly guide > - JavaEE 7(6 actually) Tutorial > - Elytron security guide > - quickstarts > - Testsuite > > Problem is that some of this guide as such make sense, but not all of them > do. > In some cases we have duplicated docs for same thing, in others we content in > wrong segment. > For example instead of having all subsystem reference docs under admin guide, > some are under Developer Guide and some even under HA guide. > > Going forward we should "refactor" docs a bit, so we would end up with 3-4 > high quality guides. > We should also go trough all docs and remove/update the outdated content. > > Plan is also to have documentation now part of WildFly codebase. > So when we would submit PR with new feature, it would also include > documentation for it as well. > > Rendered docs can be build as part of our build / release process and can be > rendered to different formats. > for example default is HTML [5] or PDF [6] > > I've send experimental PR to show how docs would fit into WildFly build [4] > > Please take look at current docs and if you have any comments / suggestions > what we can improve before merging it let me know. > At this point I've not done much content-wise changes but just conversion + > formatting ones. > Content updates can come after this is merged. > > -- > tomaz > > [1] https://docs.jboss.org/author/display/WFLY/Documentation > [2] > https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc > [3] > https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc > [4] https://github.com/wildfly/wildfly/pull/10523 > [5] https://ctomc.github.io/docs-playground/Admin_Guide.html > [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf > [7] https://github.com/ctomc/docs-playground > [8] https://ctomc.github.io/docs-playground/ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From bburke at redhat.com Wed Sep 20 09:10:43 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 20 Sep 2017 09:10:43 -0400 Subject: [wildfly-dev] WildFly asciidoc based documentation In-Reply-To: <736426731.18748051.1505905257464.JavaMail.zimbra@redhat.com> References: <736426731.18748051.1505905257464.JavaMail.zimbra@redhat.com> Message-ID: Take a look at Keycloak docs: https://github.com/keycloak/keycloak-documentation All asciidoc. They require a build a build that tests automatically tests links and any other thing that can be automatically tested. Our product docs also derive directly from community docs which makes things a lot less work for everybody. Both community and product benefit. On Wed, Sep 20, 2017 at 7:00 AM, Rostislav Svoboda wrote: > Hi Tomaz. > > How would this change translate to product branch ? > > Would it also make sense to extract parts of documentation related to "Servlet-Only Distribution" provided on http://wildfly.org/downloads/ ? > I think current documentation presumes full app server distribution. > > Maybe going further it would also make sense to compose docs via provisioning tool (https://github.com/aloubyansky/pm/) so users could have up to date documentation related to stuff they are using in their setup ... e.g. when they compose server just with undertow + resteasy + hibernate they wouldn't get documentation for clustering, soap webservices, messaging, ... > The same could also happen for Quickstarts, have them provisioned via pm (or similar) tool based on the selected components/feature packs. > > Rostislav > > ----- Original Message ----- >> Hey guys, >> >> TL;DR >> I've converted confluence docs asciidoc [1] [2] ones that will be part of >> WildFly codebase, >> take a look at them and let me know if there are any big issues. >> >> >> ---- >> full version: >> >> as most of you already know, I was working on moving our confluence based [1] >> documentation to asciidoc based one. >> >> result can be seen at [7] or rendered to html at [8] >> >> A good side effect of conversion is that now docs are also browsable directly >> on GitHub. >> For example [2] or [3] >> >> Currently I kept same structure as we had in confluence, which in practice >> means >> we have set of "guides" that than have lots of sub pages / includes that >> produce "big" guides. >> Currently such guides are: >> - Admin Guide >> - Developer Guide >> - Getting started guide >> - Getting Started Developing Applications Guide >> - High Availability Guide >> - Extending WildFly guide >> - JavaEE 7(6 actually) Tutorial >> - Elytron security guide >> - quickstarts >> - Testsuite >> >> Problem is that some of this guide as such make sense, but not all of them >> do. >> In some cases we have duplicated docs for same thing, in others we content in >> wrong segment. >> For example instead of having all subsystem reference docs under admin guide, >> some are under Developer Guide and some even under HA guide. >> >> Going forward we should "refactor" docs a bit, so we would end up with 3-4 >> high quality guides. >> We should also go trough all docs and remove/update the outdated content. >> >> Plan is also to have documentation now part of WildFly codebase. >> So when we would submit PR with new feature, it would also include >> documentation for it as well. >> >> Rendered docs can be build as part of our build / release process and can be >> rendered to different formats. >> for example default is HTML [5] or PDF [6] >> >> I've send experimental PR to show how docs would fit into WildFly build [4] >> >> Please take look at current docs and if you have any comments / suggestions >> what we can improve before merging it let me know. >> At this point I've not done much content-wise changes but just conversion + >> formatting ones. >> Content updates can come after this is merged. >> >> -- >> tomaz >> >> [1] https://docs.jboss.org/author/display/WFLY/Documentation >> [2] >> https://github.com/ctomc/docs-playground/blob/master/admin-guide/Operating_modes.adoc >> [3] >> https://github.com/ctomc/docs-playground/blob/master/developer-guide/EJB3_Reference_Guide.adoc >> [4] https://github.com/wildfly/wildfly/pull/10523 >> [5] https://ctomc.github.io/docs-playground/Admin_Guide.html >> [6] https://ctomc.github.io/docs-playground/Admin_Guide.pdf >> [7] https://github.com/ctomc/docs-playground >> [8] https://ctomc.github.io/docs-playground/ >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Bill Burke Red Hat From ebenzacar at gmail.com Wed Sep 20 11:04:33 2017 From: ebenzacar at gmail.com (Eric B) Date: Wed, 20 Sep 2017 11:04:33 -0400 Subject: [wildfly-dev] Is Artemis not included as a dependency in the Wildfly-ee poms? Message-ID: Hi, I was looking to find the full dependency list for Wildfly, so I took a look at the dependency hierarchy of the Wildfly EE server. But I do not see the Artemis server listed anywhere as a dependency. My starting point was: org.wildfly wildfly-ee 10.0.0.Final Am I looking in the wrong place, or is Artemis intentionally not included? Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170920/6b2ba81a/attachment.html From brian.stansberry at redhat.com Wed Sep 20 12:15:50 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 20 Sep 2017 11:15:50 -0500 Subject: [wildfly-dev] Is Artemis not included as a dependency in the Wildfly-ee poms? In-Reply-To: References: Message-ID: Try mvn dependency:tree -pl :wildfly-feature-pack The wildfly-ee module does not depend on everything related to ee. It's more the other way around; it provides some basic ee stuff that other subsystems need. Brian Stansberry Manager, Senior Principal Software Engineer Red Hat On Wed, Sep 20, 2017 at 10:04 AM, Eric B wrote: > Hi, > > I was looking to find the full dependency list for Wildfly, so I took a > look at the dependency hierarchy of the Wildfly EE server. But I do not > see the Artemis server listed anywhere as a dependency. > > My starting point was: > > > org.wildfly > wildfly-ee > 10.0.0.Final > > > Am I looking in the wrong place, or is Artemis intentionally not included? > > Thanks, > > Eric > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170920/7450a2d5/attachment-0001.html From rory.odonnell at oracle.com Thu Sep 21 16:50:36 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 21 Sep 2017 21:50:36 +0100 Subject: [wildfly-dev] Release Announcement: General Availability of JDK 9 Message-ID: Hi Jason/Tomaz, Three items to share with you today * *JDK 9 General Availability * o GPL'd binaries from Oracle are available here: + http://jdk.java.net/9 o See Mark Reinhold's email for more details on the Release [1] + delivery of Project Jigsaw [2] * Are you JDK 9 Ready ? o The Quality Outreach wiki has been updated to include a JDK 9 Ready column. o If you would like us to identify your project as JDK 9 ready , please let me know and I will add it to the wiki. o Wildfly 11 is listed as JDK 9 Ready. * Quality Outreach Report for September 2017**is available o many thanks for your continued support and welcome to the new projects! Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html [2] https://mreinhold.org/blog/jigsaw-complete -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170921/42e63b39/attachment.html From rsvoboda at redhat.com Fri Sep 22 03:49:42 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Fri, 22 Sep 2017 03:49:42 -0400 (EDT) Subject: [wildfly-dev] Release Announcement: General Availability of JDK 9 In-Reply-To: References: Message-ID: <1720635264.19724748.1506066582069.JavaMail.zimbra@redhat.com> Hi. Looking at https://mreinhold.org/blog/jigsaw-complete section Thanks! Where is David M. Lloyd ? Rostislav ----- Original Message ----- > Hi Jason/Tomaz, > Three items to share with you today > * JDK 9 General Availability > * GPL'd binaries from Oracle are available here: > * http://jdk.java.net/9 > * See Mark Reinhold's email for more details on the Release [1] > * delivery of Project Jigsaw [2] > * Are you JDK 9 Ready ? > * The Quality Outreach wiki has been updated to include a JDK 9 Ready column. > * If you would like us to identify your project as JDK 9 ready , please let > me know and I will add it to the wiki. > * Wildfly 11 is listed as JDK 9 Ready. > * Quality Outreach Report for September 2017 is available > * many thanks for your continued support and welcome to the new projects! > Rgds,Rory [1] > http://mail.openjdk.java.net/pipermail/announce/2017-September/000230.html > [2] https://mreinhold.org/blog/jigsaw-complete > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170922/ff73ed04/attachment.html From ehugonne at redhat.com Mon Sep 25 05:06:24 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 25 Sep 2017 11:06:24 +0200 Subject: [wildfly-dev] Updating WildFly instance with the Provisioning Tool Message-ID: <1f8c6b00-ed9c-6325-9c7d-8ee6f76f91a6@redhat.com> Hey guys, TL;DR I've been experimenting with Alexey to update a customized provisioned server using the provisioning tool [1]. I'm using the syncing operations [2] that I created a while back by porting the domain synchronization operations to standalone (to synchronize standalone instances in a cloud environment). I'm looking for some feedback on this approach. Cheers Emmanuel [1]: https://github.com/ehsavoie/pm/tree/upgrade-feature-pack [2]: https://github.com/ehsavoie/wildfly-core/tree/model_diff ---- full version: Updating WildFly Terminology Updating is the process of applying a fix pack that will increment the micro version. There should be no compatiblity issue. Upgrading is the transition of a minor version, compatiblity should be available but there are a lot more changes. While the mecanisms discussed here are general, they might need more refinement for an upgrade. Use case The use case is quite simple: *I have version 1.0.0 installed and i want to update to 1.0.1 but I have locally customized my server and i?d like to keep those changes*. We have several local elements to take into account: * filesystem changes (files added, removed or deleted). * configuration changes. The basic idea is to diff the existing instance with a pure new installation of the same version then apply those changes to a new provisioned version instance for staging. We can keep it at the basic filesystem approach with some simple merge strategy (theirs, ours). We can use the plugin to go into more details. For exemple using the model diff between standalone Wildfly instances we can create a cli script to reconfigure the upgraded instance in a post-installation step. Diffing the filesystem The idea is to compare the instance to be upgraded with one instance provisioned with the same feature packs as the one we want to upgrade. The plugin will provide a list of files or regexp to be excluded. Each file will be hashed and we compare the hash + the relative path to deduce deleted, modified or added files. For textual files we can provide a diff (and the means to apply it), but maybe that should be for a later version as some kind of interaction with the user might be required. WildFly standalone plugin This is a specialization of the upgrading algorithm: * Filtering out some of the 'unimportant' files (tmp, logs). * Creating diff of textual files (for example the realm properties) which will be applied (merging strategy ? la git). * Using an embedded standalone it creates a jboss-cli script to reconfigure the server (adding/removing extensions and reconfiguring subsystems). * Deleting files that were removed. This is done on a staging upgraded instance before being copied over the old instance. I have added a diff/sync operation in standalone that is quite similar to what happens when a slave HC connects to the DC. Thus I start the current installation, and connect to it from an embedded server using the initial configuration and diff the models. This is 'experimental' but it works nicely (I was able to 'upgrade' from the standalone.xml of wildfly-core to the standalone-full.xml of wildfly). I?m talking only about the model part, I leave the files to the filesystem 'diffing' but it wiill work with managed deployments are those are added by the filesystem part and then the deployment reference is added in the model. For a future version of the tooling/plugin we might look for a way to interract more with the user (for example for applying the textual diffs to choose what to do per file instead of globally). Also currently the filters for excluding files are defined by the plugin but we could enrich them from the tooling also. Producing an update feature pack From the initial upgrade mecanism Alexey has seen the potential to create a feature pack instead of my initial format. Currently i?m able to create and installa a feature-pack that will supersede the initial installation with its own local modifications. Thus from my customized instance I can produce a feature pack that will allow me to reinstall the same instance. Maybe this can be also use to produce upgrade feature pack for patching. WildFly domain mode Domain mode is a bit more complex, and we need to think how to manager the model changes. Those can be at the domain level or the host level and depending on the instance target we would need to get the changes from the domain.xml or/and the host.xml. I?m thinking about applying the same strategy as what was done for standalone : aka expose the sync operations to an embedded HC. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170925/4cbc922e/attachment.bin From brian.stansberry at redhat.com Mon Sep 25 11:51:24 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 25 Sep 2017 10:51:24 -0500 Subject: [wildfly-dev] Updating WildFly instance with the Provisioning Tool In-Reply-To: <1f8c6b00-ed9c-6325-9c7d-8ee6f76f91a6@redhat.com> References: <1f8c6b00-ed9c-6325-9c7d-8ee6f76f91a6@redhat.com> Message-ID: Thanks for this! I want to make sure that what comes out of this are clear decisions about what we're willing to handle in terms of various sorts of conflicts. What kinds of things the tool is responsible for solving vs what the user has to resolve, what tooling config settings we support for tweaking what the tool will do for the user, etc. When I say conflicts I don't just mean file conflicts; I also mean use case conflicts. What's the right way / wrong way to do things and what combinations are ok. Part of what makes this interesting is the provisioning tool itself is meant to be used for setting up the installation the way the user wants it. So in many many cases if there is a diff it's because the user bypassed the tool. Of course that's going to be very common, particularly when it comes to the config files, where people have been using tools like the CLI to set up their configs for years. Manually adding, removing and modifying modules, hopefully we can wean people off that and get them to use the tool, but still, people won't. The 3-way diffing approach you describe sounds like it should be flexible enough to handle various permutations. Re: the "update feature pack" what happens if the user has produced and stored one of those, then updates their base configuration, and then applies that update feature pack. So, the user has taken an install provisioned by the tool, with standalone.xml produced according to the inputs to the tool. Then modified that via CLI/HAL and saved those mods in an update feature pack. Then taken the bulk of those mods, adjusted their inputs to the provisioning tool such that tool produces the desired config, does an installation and wishes to apply that update feature pack? Detail question: "Filtering out some of the 'unimportant' files (tmp, logs)." What does that mean? The tmp and logs dirs end up empty in the new installation? That might be ok for tmp but for logs it sounds wrong. I'm not sure it's necessary for tmp. Brian Stansberry Manager, Senior Principal Software Engineer Red Hat On Mon, Sep 25, 2017 at 4:06 AM, Emmanuel Hugonnet wrote: > Hey guys, > > TL;DR > I've been experimenting with Alexey to update a customized provisioned > server using the provisioning tool [1]. > I'm using the syncing operations [2] that I created a while back by > porting the domain synchronization operations to standalone (to > synchronize standalone instances in a cloud environment). > I'm looking for some feedback on this approach. > Cheers > Emmanuel > > [1]: https://github.com/ehsavoie/pm/tree/upgrade-feature-pack > [2]: https://github.com/ehsavoie/wildfly-core/tree/model_diff > > ---- > full version: > > > Updating WildFly > > > docs/guide/wildfly/upgrade.adoc#terminology>Terminology > > Updating is the process of applying a fix pack that will increment the > micro version. There should be no compatiblity issue. Upgrading is > the transition of a minor version, compatiblity should be available but > there are a lot more changes. > > While the mecanisms discussed here are general, they might need more > refinement for an upgrade. > > > docs/guide/wildfly/upgrade.adoc#use-case>Use case > > The use case is quite simple: *I have version 1.0.0 installed and i want > to update to 1.0.1 but I have locally customized my server and i?d > like to keep those changes*. > We have several local elements to take into account: > > * > > filesystem changes (files added, removed or deleted). > > * > > configuration changes. > > The basic idea is to diff the existing instance with a pure new > installation of the same version then apply those changes to a new > provisioned version instance for staging. > We can keep it at the basic filesystem approach with some simple merge > strategy (theirs, ours). > We can use the plugin to go into more details. For exemple using the model > diff between standalone Wildfly instances we can create a cli > script to reconfigure the upgraded instance in a post-installation step. > > > docs/guide/wildfly/upgrade.adoc#diffing-the-filesystem>Diffing the > filesystem > > The idea is to compare the instance to be upgraded with one instance > provisioned with the same feature packs as the one we want to upgrade. > The plugin will provide a list of files or regexp to be excluded. > Each file will be hashed and we compare the hash + the relative path to > deduce deleted, modified or added files. > For textual files we can provide a diff (and the means to apply it), but > maybe that should be for a later version as some kind of > interaction with the user might be required. > > > docs/guide/wildfly/upgrade.adoc#wildfly-standalone-plugin>WildFly > standalone > plugin > > This is a specialization of the upgrading algorithm: > > * > > Filtering out some of the 'unimportant' files (tmp, logs). > > * > > Creating diff of textual files (for example the realm properties) > which will be applied (merging strategy ? la git). > > * > > Using an embedded standalone it creates a jboss-cli script to > reconfigure the server (adding/removing extensions and reconfiguring > subsystems). > > * > > Deleting files that were removed. > > This is done on a staging upgraded instance before being copied over the > old instance. > I have added a diff/sync operation in standalone that is quite similar to > what happens when a slave HC connects to the DC. Thus I start the > current installation, and connect to it from an embedded server using the > initial configuration and diff the models. > This is 'experimental' but it works nicely (I was able to 'upgrade' from > the standalone.xml of wildfly-core to the standalone-full.xml of > wildfly). > I?m talking only about the model part, I leave the files to the filesystem > 'diffing' but it wiill work with managed deployments are those > are added by the filesystem part and then the deployment reference is > added in the model. > For a future version of the tooling/plugin we might look for a way to > interract more with the user (for example for applying the textual > diffs to choose what to do per file instead of globally). > Also currently the filters for excluding files are defined by the plugin > but we could enrich them from the tooling also. > > > docs/guide/wildfly/upgrade.adoc#producing-an-update-feature-pack>Producing > an > update feature pack > > From the initial upgrade mecanism Alexey has seen the potential to create > a feature pack instead of my initial format. > Currently i?m able to create and installa a feature-pack that will > supersede the initial installation with its own local modifications. > Thus from my customized instance I can produce a feature pack that will > allow me to reinstall the same instance. Maybe this can be also use > to produce upgrade feature pack for patching. > > > docs/guide/wildfly/upgrade.adoc#wildfly-domain-mode>WildFly domain mode > > Domain mode is a bit more complex, and we need to think how to manager the > model changes. > Those can be at the domain level or the host level and depending on the > instance target we would need to get the changes from the domain.xml > or/and the host.xml. > I?m thinking about applying the same strategy as what was done for > standalone : aka expose the sync operations to an embedded HC. > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170925/bdc4bd5a/attachment-0001.html From ehugonne at redhat.com Mon Sep 25 12:33:43 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 25 Sep 2017 18:33:43 +0200 Subject: [wildfly-dev] Updating WildFly instance with the Provisioning Tool In-Reply-To: References: <1f8c6b00-ed9c-6325-9c7d-8ee6f76f91a6@redhat.com> Message-ID: <76ee03bf-47d6-7340-c7c0-11b88efe6b4b@redhat.com> Currently the update feature pack inherit the provisioned feature packs so he would be able to reproduce the whole installation in a single step since the 'initial' installation would be applied then the customization. So basically a user makes some changes manually and we provide him with a feature pack. The produced feature pack is not just a feature pack with the changes but a 'real' feature pack installing everything (initial installation + changes). Of course he would have to either rebuild the feature pack or adjust it when he wants to use a new version of the installation feature packs (at least update the gav coordinates in the dependencies).? Detail question answer : Currently producing a feature pack is different from updating a provisioned instance : we could specify which files to ignore based on this (logs files don't mean anything if you want to install a customized instance multiple times but shouldn't be deleted if you apply an update). Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170925/1188a45e/attachment.bin From fabian at fstab.de Tue Sep 26 17:18:30 2017 From: fabian at fstab.de (Fabian =?iso-8859-1?Q?St=E4ber?=) Date: Tue, 26 Sep 2017 23:18:30 +0200 Subject: [wildfly-dev] Equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 Message-ID: <20170926211830.GA15053@lessing> Hello, sorry if this is the wrong place to ask, but I am trying to run a Java agent with Wildfly 11 and Java 9. In previous Java versions, I had to add -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make sure the Wildfly java.util.logging.manager implementation is available to the agent. I understand that in Java 9 the -Xbootclasspath/p option is replaced with the --patch-module option. However, I am having trouble to figure out how to use this option. What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar is in Java 9 with Wildfly 11? Thanks a lot Fabian From jperkins at redhat.com Tue Sep 26 20:04:08 2017 From: jperkins at redhat.com (James Perkins) Date: Tue, 26 Sep 2017 17:04:08 -0700 Subject: [wildfly-dev] Equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 In-Reply-To: <20170926211830.GA15053@lessing> References: <20170926211830.GA15053@lessing> Message-ID: There is a system property you need to add to the JAVA_OPTS IIRC. Try adding "-Dsun.util.logging.disableCallerCheck=true". This should avoid the weird issues with the log manager. On Tue, Sep 26, 2017 at 2:18 PM, Fabian St?ber wrote: > Hello, > > sorry if this is the wrong place to ask, but I am trying to run a Java > agent with Wildfly 11 and Java 9. In previous Java versions, I had to add > -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make > sure the Wildfly java.util.logging.manager implementation is available to > the agent. > > I understand that in Java 9 the -Xbootclasspath/p option is replaced with > the --patch-module option. However, I am having trouble to figure out how > to use this option. > > What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar > is in Java 9 with Wildfly 11? > > Thanks a lot > Fabian > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170926/c32336a7/attachment.html From postmaster at lists.jboss.org Wed Sep 27 01:54:52 2017 From: postmaster at lists.jboss.org (postmaster at lists.jboss.org) Date: Wed, 27 Sep 2017 13:54:52 +0800 (CST) Subject: [wildfly-dev] =?gbk?b?0snLxsCsu/jTyrz+o6zH69fQz7i87LLp0tTD4tOw?= =?gbk?b?z+zE+rXEuaTX96Oh?= Message-ID: <201709270618.v8R6IMti000817@lists01.dmz-a.mwc.hst.phx2.redhat.com> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170927/dd609d10/attachment.html From tomaz.cerar at gmail.com Wed Sep 27 05:45:12 2017 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Wed, 27 Sep 2017 11:45:12 +0200 Subject: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 In-Reply-To: References: <20170926211830.GA15053@lessing> Message-ID: <59cb7328.8388500a.d9e7.5992@mx.google.com> Hey, Keep in mind that while WildFly 11 does run fine on JDK9. It still does that in ?classpath? mode not in pure modular(jigsaw) fashion. As such ?patch-module for WildFly modules (jboss-modules) does not apply (yet) You should be fine by just using your agent with jboss-modules on CP and system property that James suggested. -- Tomaz From: James Perkins Sent: sreda, 27. september 2017 02:45 To: Fabian St?ber Cc: wildfly-dev at lists.jboss.org Subject: Re: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 There is a system property you need to add to the JAVA_OPTS IIRC. Try adding "-Dsun.util.logging.disableCallerCheck=true". This should avoid the weird issues with the log manager. On Tue, Sep 26, 2017 at 2:18 PM, Fabian St?ber wrote: Hello, sorry if this is the wrong place to ask, but I am trying to run a Java agent with Wildfly 11 and Java 9. In previous Java versions, I had to add -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make sure the Wildfly java.util.logging.manager implementation is available to the agent. I understand that in Java 9 the -Xbootclasspath/p option is replaced with the --patch-module option. However, I am having trouble to figure out how to use this option. What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar is in Java 9 with Wildfly 11? Thanks a lot Fabian _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170927/bc63e238/attachment.html From fabian at fstab.de Wed Sep 27 10:07:50 2017 From: fabian at fstab.de (Fabian =?iso-8859-1?Q?St=E4ber?=) Date: Wed, 27 Sep 2017 16:07:50 +0200 Subject: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 In-Reply-To: <59cb7328.8388500a.d9e7.5992@mx.google.com> References: <20170926211830.GA15053@lessing> <59cb7328.8388500a.d9e7.5992@mx.google.com> Message-ID: <20170927140749.GA1599@lessing> Hello, I am sorry, but I still don't get it. My agent initializes the java.util.logging.manager (indirectly, because it registers a JMX bean, and platform MBean server has an internal dependency to logging). This is done before any Wildfly code is loaded. I understand that this works with Wildfly only if the agent uses org.jboss.logmanager.LogManager as the log manager implementation. With Java 8, this can be done with the following start script: cd ./wildfly-10.1.0.Final LOGMANAGER_JAR=$(find $(pwd) -name 'jboss-logmanager-*.jar') export JAVA_OPTS=" -Xbootclasspath/p:${LOGMANAGER_JAR} -Djboss.modules.system.pkgs=org.jboss.logmanager,io.promagent.agent -Djava.util.logging.manager=org.jboss.logmanager.LogManager -javaagent:promagent.jar=port=9300 " ./bin/standalone.sh The question is, how do I make jboss-logmanager-2.0.7.Final.jar available to the agent's class loader with Java 9? The "-Xbootclasspath/p:" option was removed, but the agent needs access to the org.jboss.logmanager.LogManager class to initialize logging correctly (Wildfly doesn't seem to run when the agent initializes logging with the default log manager). Thanks for your help Fabian On Wed, Sep 27, 2017 at 11:45:12AM +0200, Toma? Cerar wrote: > Hey, > Keep in mind that while WildFly 11 does run fine on JDK9. > It still does that in ?classpath? mode not in pure modular(jigsaw) fashion. > > As such ?patch-module for WildFly modules (jboss-modules) does not apply (yet) > > You should be fine by just using your agent with jboss-modules on CP and system property that James suggested. > > -- > Tomaz > > From: James Perkins > Sent: sreda, 27. september 2017 02:45 > To: Fabian St?ber > Cc: wildfly-dev at lists.jboss.org > Subject: Re: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 > > There is a system property you need to add to the JAVA_OPTS IIRC. Try adding "-Dsun.util.logging.disableCallerCheck=true". This should avoid the weird issues with the log manager. > > On Tue, Sep 26, 2017 at 2:18 PM, Fabian St?ber wrote: > Hello, > > sorry if this is the wrong place to ask, but I am trying to run a Java agent with Wildfly 11 and Java 9. In previous Java versions, I had to add -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make sure the Wildfly java.util.logging.manager implementation is available to the agent. > > I understand that in Java 9 the -Xbootclasspath/p option is replaced with the --patch-module option. However, I am having trouble to figure out how to use this option. > > What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar is in Java 9 with Wildfly 11? > > Thanks a lot > Fabian > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat > From jperkins at redhat.com Wed Sep 27 11:16:49 2017 From: jperkins at redhat.com (James Perkins) Date: Wed, 27 Sep 2017 08:16:49 -0700 Subject: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 In-Reply-To: <20170927140749.GA1599@lessing> References: <20170926211830.GA15053@lessing> <59cb7328.8388500a.d9e7.5992@mx.google.com> <20170927140749.GA1599@lessing> Message-ID: My apologies for misunderstanding. The -Xbootclasspath/a is still supported which would likely work for you. On Wed, Sep 27, 2017 at 7:07 AM, Fabian St?ber wrote: > Hello, > > I am sorry, but I still don't get it. > > My agent initializes the java.util.logging.manager (indirectly, because it > registers a JMX bean, and platform MBean server has an internal dependency > to logging). This is done before any Wildfly code is loaded. > > I understand that this works with Wildfly only if the agent uses > org.jboss.logmanager.LogManager as the log manager implementation. With > Java 8, this can be done with the following start script: > > cd ./wildfly-10.1.0.Final > LOGMANAGER_JAR=$(find $(pwd) -name 'jboss-logmanager-*.jar') > export JAVA_OPTS=" > -Xbootclasspath/p:${LOGMANAGER_JAR} > -Djboss.modules.system.pkgs=org.jboss.logmanager,io. > promagent.agent > -Djava.util.logging.manager=org.jboss.logmanager.LogManager > -javaagent:promagent.jar=port=9300 > " > ./bin/standalone.sh > > The question is, how do I make jboss-logmanager-2.0.7.Final.jar available > to the agent's class loader with Java 9? The "-Xbootclasspath/p:" option > was removed, but the agent needs access to the org.jboss.logmanager.LogManager > class to initialize logging correctly (Wildfly doesn't seem to run when the > agent initializes logging with the default log manager). > > Thanks for your help > Fabian > > On Wed, Sep 27, 2017 at 11:45:12AM +0200, Toma? Cerar wrote: > > Hey, > > Keep in mind that while WildFly 11 does run fine on JDK9. > > It still does that in ?classpath? mode not in pure modular(jigsaw) > fashion. > > > > As such ?patch-module for WildFly modules (jboss-modules) does not apply > (yet) > > > > You should be fine by just using your agent with jboss-modules on CP and > system property that James suggested. > > > > -- > > Tomaz > > > > From: James Perkins > > Sent: sreda, 27. september 2017 02:45 > > To: Fabian St?ber > > Cc: wildfly-dev at lists.jboss.org > > Subject: Re: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar > in Java 9 > > > > There is a system property you need to add to the JAVA_OPTS IIRC. Try > adding "-Dsun.util.logging.disableCallerCheck=true". This should avoid > the weird issues with the log manager. > > > > On Tue, Sep 26, 2017 at 2:18 PM, Fabian St?ber wrote: > > Hello, > > > > sorry if this is the wrong place to ask, but I am trying to run a Java > agent with Wildfly 11 and Java 9. In previous Java versions, I had to add > -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make > sure the Wildfly java.util.logging.manager implementation is available to > the agent. > > > > I understand that in Java 9 the -Xbootclasspath/p option is replaced > with the --patch-module option. However, I am having trouble to figure out > how to use this option. > > > > What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar > is in Java 9 with Wildfly 11? > > > > Thanks a lot > > Fabian > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > James R. Perkins > > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170927/3ac34994/attachment.html From jperkins at redhat.com Wed Sep 27 11:40:54 2017 From: jperkins at redhat.com (James Perkins) Date: Wed, 27 Sep 2017 08:40:54 -0700 Subject: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 In-Reply-To: References: <20170926211830.GA15053@lessing> <59cb7328.8388500a.d9e7.5992@mx.google.com> <20170927140749.GA1599@lessing> Message-ID: FWIW I tested with the following and it worked fine on WIldFly 10.1.0.Final and WildFly 11.0.0.Beta1 for me. cd ./wildfly-10.1.0.Final LOGMANAGER_JAR=$(find $(pwd) -name 'jboss-logmanager-*.jar') export JAVA_OPTS="-Djboss.modules.system.pkgs=org.jboss.logmanager \ -Djava.util.logging.manager=org.jboss.logmanager.LogManager \ -Dsun.util.logging.disableCallerCheck=true \ -Xbootclasspath/a:${LOGMANAGER_JAR}" ./bin/standalone.sh On Wed, Sep 27, 2017 at 8:16 AM, James Perkins wrote: > My apologies for misunderstanding. The -Xbootclasspath/a is still > supported which would likely work for you. > > On Wed, Sep 27, 2017 at 7:07 AM, Fabian St?ber wrote: > >> Hello, >> >> I am sorry, but I still don't get it. >> >> My agent initializes the java.util.logging.manager (indirectly, because >> it registers a JMX bean, and platform MBean server has an internal >> dependency to logging). This is done before any Wildfly code is loaded. >> >> I understand that this works with Wildfly only if the agent uses >> org.jboss.logmanager.LogManager as the log manager implementation. With >> Java 8, this can be done with the following start script: >> >> cd ./wildfly-10.1.0.Final >> LOGMANAGER_JAR=$(find $(pwd) -name 'jboss-logmanager-*.jar') >> export JAVA_OPTS=" >> -Xbootclasspath/p:${LOGMANAGER_JAR} >> -Djboss.modules.system.pkgs=org.jboss.logmanager,io.promagen >> t.agent >> -Djava.util.logging.manager=org.jboss.logmanager.LogManager >> -javaagent:promagent.jar=port=9300 >> " >> ./bin/standalone.sh >> >> The question is, how do I make jboss-logmanager-2.0.7.Final.jar >> available to the agent's class loader with Java 9? The "-Xbootclasspath/p:" >> option was removed, but the agent needs access to the >> org.jboss.logmanager.LogManager class to initialize logging correctly >> (Wildfly doesn't seem to run when the agent initializes logging with the >> default log manager). >> >> Thanks for your help >> Fabian >> >> On Wed, Sep 27, 2017 at 11:45:12AM +0200, Toma? Cerar wrote: >> > Hey, >> > Keep in mind that while WildFly 11 does run fine on JDK9. >> > It still does that in ?classpath? mode not in pure modular(jigsaw) >> fashion. >> > >> > As such ?patch-module for WildFly modules (jboss-modules) does not >> apply (yet) >> > >> > You should be fine by just using your agent with jboss-modules on CP >> and system property that James suggested. >> > >> > -- >> > Tomaz >> > >> > From: James Perkins >> > Sent: sreda, 27. september 2017 02:45 >> > To: Fabian St?ber >> > Cc: wildfly-dev at lists.jboss.org >> > Subject: Re: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar >> in Java 9 >> > >> > There is a system property you need to add to the JAVA_OPTS IIRC. Try >> adding "-Dsun.util.logging.disableCallerCheck=true". This should avoid >> the weird issues with the log manager. >> > >> > On Tue, Sep 26, 2017 at 2:18 PM, Fabian St?ber wrote: >> > Hello, >> > >> > sorry if this is the wrong place to ask, but I am trying to run a Java >> agent with Wildfly 11 and Java 9. In previous Java versions, I had to add >> -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make >> sure the Wildfly java.util.logging.manager implementation is available to >> the agent. >> > >> > I understand that in Java 9 the -Xbootclasspath/p option is replaced >> with the --patch-module option. However, I am having trouble to figure out >> how to use this option. >> > >> > What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar >> is in Java 9 with Wildfly 11? >> > >> > Thanks a lot >> > Fabian >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > >> > >> > -- >> > James R. Perkins >> > JBoss by Red Hat >> > >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > James R. Perkins > JBoss by Red Hat > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170927/6cfbf6d7/attachment.html From fabian at fstab.de Wed Sep 27 15:26:41 2017 From: fabian at fstab.de (Fabian =?iso-8859-1?Q?St=E4ber?=) Date: Wed, 27 Sep 2017 21:26:41 +0200 Subject: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar in Java 9 In-Reply-To: References: <20170926211830.GA15053@lessing> <59cb7328.8388500a.d9e7.5992@mx.google.com> <20170927140749.GA1599@lessing> Message-ID: <20170927192641.GA5944@lessing.fritz.box> Great, this works! Didn't know -Xbootclasspath/a: is still supported. Thanks a lot! On Wed, Sep 27, 2017 at 08:40:54AM -0700, James Perkins wrote: > FWIW I tested with the following and it worked fine on WIldFly 10.1.0.Final > and WildFly 11.0.0.Beta1 for me. > > cd ./wildfly-10.1.0.Final > LOGMANAGER_JAR=$(find $(pwd) -name 'jboss-logmanager-*.jar') > export JAVA_OPTS="-Djboss.modules.system.pkgs=org.jboss.logmanager \ > -Djava.util.logging.manager=org.jboss.logmanager.LogManager \ > -Dsun.util.logging.disableCallerCheck=true \ > -Xbootclasspath/a:${LOGMANAGER_JAR}" > ./bin/standalone.sh > > On Wed, Sep 27, 2017 at 8:16 AM, James Perkins wrote: > > > My apologies for misunderstanding. The -Xbootclasspath/a is still > > supported which would likely work for you. > > > > On Wed, Sep 27, 2017 at 7:07 AM, Fabian St?ber wrote: > > > >> Hello, > >> > >> I am sorry, but I still don't get it. > >> > >> My agent initializes the java.util.logging.manager (indirectly, because > >> it registers a JMX bean, and platform MBean server has an internal > >> dependency to logging). This is done before any Wildfly code is loaded. > >> > >> I understand that this works with Wildfly only if the agent uses > >> org.jboss.logmanager.LogManager as the log manager implementation. With > >> Java 8, this can be done with the following start script: > >> > >> cd ./wildfly-10.1.0.Final > >> LOGMANAGER_JAR=$(find $(pwd) -name 'jboss-logmanager-*.jar') > >> export JAVA_OPTS=" > >> -Xbootclasspath/p:${LOGMANAGER_JAR} > >> -Djboss.modules.system.pkgs=org.jboss.logmanager,io.promagen > >> t.agent > >> -Djava.util.logging.manager=org.jboss.logmanager.LogManager > >> -javaagent:promagent.jar=port=9300 > >> " > >> ./bin/standalone.sh > >> > >> The question is, how do I make jboss-logmanager-2.0.7.Final.jar > >> available to the agent's class loader with Java 9? The "-Xbootclasspath/p:" > >> option was removed, but the agent needs access to the > >> org.jboss.logmanager.LogManager class to initialize logging correctly > >> (Wildfly doesn't seem to run when the agent initializes logging with the > >> default log manager). > >> > >> Thanks for your help > >> Fabian > >> > >> On Wed, Sep 27, 2017 at 11:45:12AM +0200, Toma? Cerar wrote: > >> > Hey, > >> > Keep in mind that while WildFly 11 does run fine on JDK9. > >> > It still does that in ?classpath? mode not in pure modular(jigsaw) > >> fashion. > >> > > >> > As such ?patch-module for WildFly modules (jboss-modules) does not > >> apply (yet) > >> > > >> > You should be fine by just using your agent with jboss-modules on CP > >> and system property that James suggested. > >> > > >> > -- > >> > Tomaz > >> > > >> > From: James Perkins > >> > Sent: sreda, 27. september 2017 02:45 > >> > To: Fabian St?ber > >> > Cc: wildfly-dev at lists.jboss.org > >> > Subject: Re: [wildfly-dev] Equivalent to-Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar > >> in Java 9 > >> > > >> > There is a system property you need to add to the JAVA_OPTS IIRC. Try > >> adding "-Dsun.util.logging.disableCallerCheck=true". This should avoid > >> the weird issues with the log manager. > >> > > >> > On Tue, Sep 26, 2017 at 2:18 PM, Fabian St?ber wrote: > >> > Hello, > >> > > >> > sorry if this is the wrong place to ask, but I am trying to run a Java > >> agent with Wildfly 11 and Java 9. In previous Java versions, I had to add > >> -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar to JAVA_OPTS to make > >> sure the Wildfly java.util.logging.manager implementation is available to > >> the agent. > >> > > >> > I understand that in Java 9 the -Xbootclasspath/p option is replaced > >> with the --patch-module option. However, I am having trouble to figure out > >> how to use this option. > >> > > >> > What is the equivalent to -Xbootclasspath/p:jboss-logmanager-2.0.7.Final.jar > >> is in Java 9 with Wildfly 11? > >> > > >> > Thanks a lot > >> > Fabian > >> > _______________________________________________ > >> > wildfly-dev mailing list > >> > wildfly-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > >> > > >> > > >> > > >> > -- > >> > James R. Perkins > >> > JBoss by Red Hat > >> > > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > > > > > -- > > James R. Perkins > > JBoss by Red Hat > > > > > > -- > James R. Perkins > JBoss by Red Hat From jmesnil at redhat.com Thu Sep 28 04:11:05 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 28 Sep 2017 10:11:05 +0200 Subject: [wildfly-dev] [proposal] Move legacy extensions to a separate feature pack Message-ID: <4F789ABA-1BE9-49D2-A46E-6F4143B31686@redhat.com> Hi, We had some discussion recently about improving the release process & development of WildFly after the release of WildFly 11. One of the proposal was to avoid building and testing code that is not changing often from WildFly every time the project is built. A good candidate for that kind of code is the legacy extensions. A legacy extension is a WildFly extension that is no longer usable (they have no runtime) but still provides a management model that can be in some case be migrated to newer extensions. For example: * web > undertow * messaging > messaging-activemq * jacorb > iiop-openjdk Other legacy extensions are not migrated (cmp, jaxr and configadmin). (jacorb legacy extension is a bit different as it is still usable by leveraging the runtime of iiop-openjdk aiui). The legacy extensions are frozen. Their management model is frozen and they only require changes when the new corresponding extensions have some changes that required to be taken into account during migration. But every time we build and release WildFly, we have to compile and test that unchanged code. I started a proof of concept that provides a feature pack (wildfly-legacy-feature-pack) that contains legacy extensions so they can be removed from WildFly codebase: https://github.com/jmesnil/wildfly-legacy These legacy extensions are provided by the wildfly-legacy-feature-pack that contains everything to install them in WildFly (module definitions and jars). Wildfly?s own feature-pack then depends on it[1] so that the actual distribution of WildFly is not different from the current one. But a lot of code can be removed from the wildfly codebase by moving these extensions to a separate project. Since legacy extensions have no runtime and only a management model, they have few dependencies and relies only on the wildfly-core-feature-pack. There is just an interesting problem with the migrate operation that some of these extensions define (web and messaging). The code of the :migrate operation itself is not dependent on the new extensions as it only manipulates DMR operations. However the functional test of the :migrate operation requires the new extension to be able to validate that the management model of the legacy extension has been properly migrated to a valid management model of the new extension. This means that the legacy extensions depends on the new extensions (defined in wildfly) *with a test scope*[2]. This introduces a circular dependency between wildfly (that depends on the wildlfy-legacy-feature-pack) and the wildfly-legacy-feature-pack (that depends on wildfly extensions *with test scope*). Since one of the dependency is in scope test, I worked around that by depending on the n-1 version of wildfly from wildlfy-legacy-feature-pack. It?s not ideal but in practice I?m not sure it is a big issue. Maintainers of legacy extensions can build local snapshots of WildFly and use it as a dependency for the legacy-feature-pack when there might be some changes that impact the legacy extensions. The only legacy extension that I could not move is the jacorb one. This one is tightly bound to the new iiop-openjdk extension. It inherits from its classes to provide its runtime emulation. Moving the other legacy extensions still reduces the size of WildFly with 230-ish files removed and almost 50K lines: $ git diff --shortstat master legacy-feature-pack 233 files changed, 14 insertions(+), 49832 deletions(-) What do you think? Once we have released WildFly 11, would it be worth moving legacy extensions to a separate feature pack? [1] https://github.com/jmesnil/wildfly-legacy [2] https://github.com/jmesnil/wildfly-legacy/blob/7b4c548033a3f652380567df60f8596d570c8db9/pom.xml#L305-L317 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Thu Sep 28 11:13:41 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 28 Sep 2017 10:13:41 -0500 Subject: [wildfly-dev] [proposal] Move legacy extensions to a separate feature pack In-Reply-To: <4F789ABA-1BE9-49D2-A46E-6F4143B31686@redhat.com> References: <4F789ABA-1BE9-49D2-A46E-6F4143B31686@redhat.com> Message-ID: Sounds good to me. I don't want to make this sound like a priority or a blocker to what you describe, but it would be nice if we could figure out a clean way to reverse roles a bit when it comes to migrate ops. In the end it's the *new* subsystem that has a responsibility to support migration, and it's the new subsystem that has the potential to break migration. The management model of the old subsystem is fixed and known. We expose the migrate ops as API of the old subsystem for solid UX reasons, but really it's the new stuff that has to ensure they work correctly. Can something like the undertow (extension) maven module in WF have a test-only dep on a legacy FP, and then use that to build up a legacy config and migrate it? I've forgotten if our subsystem test stuff supports having two separate extensions involved. Brian Stansberry Manager, Senior Principal Software Engineer Red Hat On Thu, Sep 28, 2017 at 3:11 AM, Jeff Mesnil wrote: > Hi, > > We had some discussion recently about improving the release process & > development of WildFly after the release of WildFly 11. > > One of the proposal was to avoid building and testing code that is not > changing often from WildFly every time the project is built. > A good candidate for that kind of code is the legacy extensions. > > A legacy extension is a WildFly extension that is no longer usable (they > have no runtime) but still provides a management model that can be in some > case be migrated to newer extensions. > For example: > * web > undertow > * messaging > messaging-activemq > * jacorb > iiop-openjdk > Other legacy extensions are not migrated (cmp, jaxr and configadmin). > (jacorb legacy extension is a bit different as it is still usable by > leveraging the runtime of iiop-openjdk aiui). > > The legacy extensions are frozen. Their management model is frozen and > they only require changes when the new corresponding extensions have some > changes that required to be taken into account during migration. > But every time we build and release WildFly, we have to compile and test > that unchanged code. > > I started a proof of concept that provides a feature pack > (wildfly-legacy-feature-pack) > that contains legacy extensions so they can be removed from WildFly > codebase: > > https://github.com/jmesnil/wildfly-legacy > > These legacy extensions are provided by the wildfly-legacy-feature-pack > that contains everything to install them in WildFly (module definitions and > jars). > Wildfly?s own feature-pack then depends on it[1] so that the actual > distribution of WildFly is not different from the current one. > But a lot of code can be removed from the wildfly codebase by moving these > extensions to a separate project. > > Since legacy extensions have no runtime and only a management model, they > have few dependencies and relies only on the wildfly-core-feature-pack. > > There is just an interesting problem with the migrate operation that some > of these extensions define (web and messaging). > The code of the :migrate operation itself is not dependent on the new > extensions as it only manipulates DMR operations. > However the functional test of the :migrate operation requires the new > extension to be able to validate that the management model of the legacy > extension has been properly migrated to a valid management model of the new > extension. > > This means that the legacy extensions depends on the new extensions > (defined in wildfly) *with a test scope*[2]. > > This introduces a circular dependency between wildfly (that depends on the > wildlfy-legacy-feature-pack) and the wildfly-legacy-feature-pack (that > depends on wildfly extensions *with test scope*). > Since one of the dependency is in scope test, I worked around that by > depending on the n-1 version of wildfly from wildlfy-legacy-feature-pack. > It?s not ideal but in practice I?m not sure it is a big issue. > Maintainers of legacy extensions can build local snapshots of WildFly and > use it as a dependency for the legacy-feature-pack when there might be some > changes that impact the legacy extensions. > > The only legacy extension that I could not move is the jacorb one. This > one is tightly bound to the new iiop-openjdk extension. It inherits from > its classes to provide its runtime emulation. > > Moving the other legacy extensions still reduces the size of WildFly with > 230-ish files removed and almost 50K lines: > > $ git diff --shortstat master legacy-feature-pack > 233 files changed, 14 insertions(+), 49832 deletions(-) > > What do you think? > Once we have released WildFly 11, would it be worth moving legacy > extensions to a separate feature pack? > > [1] https://github.com/jmesnil/wildfly-legacy > [2] https://github.com/jmesnil/wildfly-legacy/blob/ > 7b4c548033a3f652380567df60f8596d570c8db9/pom.xml#L305-L317 > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170928/2d584452/attachment.html From kkhan at redhat.com Thu Sep 28 12:15:03 2017 From: kkhan at redhat.com (Kabir Khan) Date: Thu, 28 Sep 2017 18:15:03 +0200 Subject: [wildfly-dev] [proposal] Move legacy extensions to a separate feature pack In-Reply-To: References: <4F789ABA-1BE9-49D2-A46E-6F4143B31686@redhat.com> Message-ID: <0836ACEE-A72B-4FAC-8336-4A46B328927A@redhat.com> > On 28 Sep 2017, at 17:13, Brian Stansberry wrote: > > Sounds good to me. > > I don't want to make this sound like a priority or a blocker to what you describe, but it would be nice if we could figure out a clean way to reverse roles a bit when it comes to migrate ops. In the end it's the *new* subsystem that has a responsibility to support migration, and it's the new subsystem that has the potential to break migration. The management model of the old subsystem is fixed and known. We expose the migrate ops as API of the old subsystem for solid UX reasons, but really it's the new stuff that has to ensure they work correctly. > > Can something like the undertow (extension) maven module in WF have a test-only dep on a legacy FP, and then use that to build up a legacy config and migrate it? I've forgotten if our subsystem test stuff supports having two separate extensions involved. It supports adding more extensions via an AdditionalInitialization, e.g.: https://github.com/wildfly/wildfly-core/blob/master/subsystem-test/tests/src/test/java/org/jboss/as/subsystem/test/extrasubsystem/subsystem/ExtraSubsystemTestCase.java#L196 > > > > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > > On Thu, Sep 28, 2017 at 3:11 AM, Jeff Mesnil wrote: > Hi, > > We had some discussion recently about improving the release process & development of WildFly after the release of WildFly 11. > > One of the proposal was to avoid building and testing code that is not changing often from WildFly every time the project is built. > A good candidate for that kind of code is the legacy extensions. > > A legacy extension is a WildFly extension that is no longer usable (they have no runtime) but still provides a management model that can be in some case be migrated to newer extensions. > For example: > * web > undertow > * messaging > messaging-activemq > * jacorb > iiop-openjdk > Other legacy extensions are not migrated (cmp, jaxr and configadmin). > (jacorb legacy extension is a bit different as it is still usable by leveraging the runtime of iiop-openjdk aiui). > > The legacy extensions are frozen. Their management model is frozen and they only require changes when the new corresponding extensions have some changes that required to be taken into account during migration. > But every time we build and release WildFly, we have to compile and test that unchanged code. > > I started a proof of concept that provides a feature pack (wildfly-legacy-feature-pack) > that contains legacy extensions so they can be removed from WildFly codebase: > > https://github.com/jmesnil/wildfly-legacy > > These legacy extensions are provided by the wildfly-legacy-feature-pack that contains everything to install them in WildFly (module definitions and jars). > Wildfly?s own feature-pack then depends on it[1] so that the actual distribution of WildFly is not different from the current one. > But a lot of code can be removed from the wildfly codebase by moving these extensions to a separate project. > > Since legacy extensions have no runtime and only a management model, they have few dependencies and relies only on the wildfly-core-feature-pack. > > There is just an interesting problem with the migrate operation that some of these extensions define (web and messaging). > The code of the :migrate operation itself is not dependent on the new extensions as it only manipulates DMR operations. > However the functional test of the :migrate operation requires the new extension to be able to validate that the management model of the legacy extension has been properly migrated to a valid management model of the new extension. > > This means that the legacy extensions depends on the new extensions (defined in wildfly) *with a test scope*[2]. > > This introduces a circular dependency between wildfly (that depends on the wildlfy-legacy-feature-pack) and the wildfly-legacy-feature-pack (that depends on wildfly extensions *with test scope*). > Since one of the dependency is in scope test, I worked around that by depending on the n-1 version of wildfly from wildlfy-legacy-feature-pack. It?s not ideal but in practice I?m not sure it is a big issue. > Maintainers of legacy extensions can build local snapshots of WildFly and use it as a dependency for the legacy-feature-pack when there might be some changes that impact the legacy extensions. > > The only legacy extension that I could not move is the jacorb one. This one is tightly bound to the new iiop-openjdk extension. It inherits from its classes to provide its runtime emulation. > > Moving the other legacy extensions still reduces the size of WildFly with 230-ish files removed and almost 50K lines: > > $ git diff --shortstat master legacy-feature-pack > 233 files changed, 14 insertions(+), 49832 deletions(-) > > What do you think? > Once we have released WildFly 11, would it be worth moving legacy extensions to a separate feature pack? > > [1] https://github.com/jmesnil/wildfly-legacy > [2] https://github.com/jmesnil/wildfly-legacy/blob/7b4c548033a3f652380567df60f8596d570c8db9/pom.xml#L305-L317 > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Thu Sep 28 16:14:35 2017 From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=) Date: Thu, 28 Sep 2017 22:14:35 +0200 Subject: [wildfly-dev] [proposal] Move legacy extensions to a separatefeature pack In-Reply-To: References: <4F789ABA-1BE9-49D2-A46E-6F4143B31686@redhat.com> Message-ID: <59cd582b.51421c0a.5f9f4.33f2@mx.google.com> ? Can something like the undertow (extension) maven module in WF have a test-only dep on a legacy FP, and then use that to build up a legacy config and migrate it? I've forgotten if our subsystem test stuff supports having two separate extensions involved. Yes, that should be doable. From: Brian Stansberry Sent: ?etrtek, 28. september 2017 17:26 To: Jeff Mesnil Cc: WildFly Dev Subject: Re: [wildfly-dev] [proposal] Move legacy extensions to a separatefeature pack Sounds good to me. I don't want to make this sound like a priority or a blocker to what you describe, but it would be nice if we could figure out a clean way to reverse roles a bit when it comes to migrate ops. In the end it's the *new* subsystem that has a responsibility to support migration, and it's the new subsystem that has the potential to break migration. The management model of the old subsystem is fixed and known. We expose the migrate ops as API of the old subsystem for solid UX reasons, but really it's the new stuff that has to ensure they work correctly. Can something like the undertow (extension) maven module in WF have a test-only dep on a legacy FP, and then use that to build up a legacy config and migrate it? I've forgotten if our subsystem test stuff supports having two separate extensions involved. Brian Stansberry Manager, Senior Principal Software Engineer Red Hat On Thu, Sep 28, 2017 at 3:11 AM, Jeff Mesnil wrote: Hi, We had some discussion recently about improving the release process & development of WildFly after the release of WildFly 11. One of the proposal was to avoid building and testing code that is not changing often from WildFly every time the project is built. A good candidate for that kind of code is the legacy extensions. A legacy extension is a WildFly extension that is no longer usable (they have no runtime) but still provides a management model that can be in some case be migrated to newer extensions. For example: * web > undertow * messaging > messaging-activemq * jacorb > iiop-openjdk Other legacy extensions are not migrated (cmp, jaxr and configadmin). (jacorb legacy extension is a bit different as it is still usable by leveraging the runtime of iiop-openjdk aiui). The legacy extensions are frozen. Their management model is frozen and they only require changes when the new corresponding extensions have some changes that required to be taken into account during migration. But every time we build and release WildFly, we have to compile and test that unchanged code. I started a proof of concept that provides a feature pack (wildfly-legacy-feature-pack) that contains legacy extensions so they can be removed from WildFly codebase: https://github.com/jmesnil/wildfly-legacy These legacy extensions are provided by the wildfly-legacy-feature-pack that contains everything to install them in WildFly (module definitions and jars). Wildfly?s own feature-pack then depends on it[1] so that the actual distribution of WildFly is not different from the current one. But a lot of code can be removed from the wildfly codebase by moving these extensions to a separate project. Since legacy extensions have no runtime and only a management model, they have few dependencies and relies only on the wildfly-core-feature-pack. There is just an interesting problem with the migrate operation that some of these extensions define (web and messaging). The code of the :migrate operation itself is not dependent on the new extensions as it only manipulates DMR operations. However the functional test of the :migrate operation requires the new extension to be able to validate that the management model of the legacy extension has been properly migrated to a valid management model of the new extension. This means that the legacy extensions depends on the new extensions (defined in wildfly) *with a test scope*[2]. This introduces a circular dependency between wildfly (that depends on the wildlfy-legacy-feature-pack) and the wildfly-legacy-feature-pack (that depends on wildfly extensions *with test scope*). Since one of the dependency is in scope test, I worked around that by depending on the n-1 version of wildfly from wildlfy-legacy-feature-pack. It?s not ideal but in practice I?m not sure it is a big issue. Maintainers of legacy extensions can build local snapshots of WildFly and use it as a dependency for the legacy-feature-pack when there might be some changes that impact the legacy extensions. The only legacy extension that I could not move is the jacorb one. This one is tightly bound to the new iiop-openjdk extension. It inherits from its classes to provide its runtime emulation. Moving the other legacy extensions still reduces the size of WildFly with 230-ish files removed and almost 50K lines: $? git diff --shortstat? master legacy-feature-pack ?233 files changed, 14 insertions(+), 49832 deletions(-) What do you think? Once we have released WildFly 11, would it be worth moving legacy extensions to a separate feature pack? [1] https://github.com/jmesnil/wildfly-legacy [2] https://github.com/jmesnil/wildfly-legacy/blob/7b4c548033a3f652380567df60f8596d570c8db9/pom.xml#L305-L317 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170928/6c3b6e70/attachment-0001.html From jmesnil at redhat.com Fri Sep 29 11:59:48 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 29 Sep 2017 17:59:48 +0200 Subject: [wildfly-dev] [proposal] Move legacy extensions to a separatefeature pack In-Reply-To: <59cd582b.51421c0a.5f9f4.33f2@mx.google.com> References: <4F789ABA-1BE9-49D2-A46E-6F4143B31686@redhat.com> <59cd582b.51421c0a.5f9f4.33f2@mx.google.com> Message-ID: > On 28 Sep 2017, at 22:14, Toma? Cerar wrote: > > ? Can something like the undertow (extension) maven module in WF have a test-only dep on a legacy FP, and then use that to build up a legacy config and migrate it? I've forgotten if our subsystem test stuff supports having two separate extensions involved. > Yes, that should be doable. Thanks, that was a good suggestion and it works fine. The migration tests were already using the subsystem-test mechanism to load both legacy and new extensions from the same test. I just moved the migration tests from the legacy code to the new one and added a test dependency to the legacy extension. This way, the legacy feature pack no longer needs any dependency to wildfly artifacts. It makes sense to run the migration tests from the new extensions: it?s up to them to check that they can still allow migration from the legacy ones when they are updated. After WildFly 11 is released, I?ll create a new wildly-legacy project in GitHub and open a PR to move the legacy extensions to it. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/