[GitHub] maven-surefire issue #166: Support filtering of tests from Base Class (TestN...
Github user krmahadevan commented on the issue: https://github.com/apache/maven-surefire/pull/166 ping @Tibor17 - This PR basically addresses only the *TestNG* portion of the bug https://github.com/cbeust/testng/issues/1563 --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-surefire pull request #166: Support filtering of tests from Base Class...
GitHub user krmahadevan opened a pull request: https://github.com/apache/maven-surefire/pull/166 Support filtering of tests from Base Class (TestNG) User has two test classes 1. An abstract base class called âBaseTestâ which contains an @Test method called âtestMethodFromBaseâ 2. A child class called âChildTestâ which extends âBaseTestâ. User attempts at running the TestNG test via -Dtest=ChildTest#testMethodFromBaseâ. Surefire plugin errors out. Fixed this anomaly for TestNG provider. You can merge this pull request into a Git repository by running: $ git pull https://github.com/krmahadevan/maven-surefire krmahadevan-supportBaseClassTestFilteringUsingTestNG Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/166.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #166 commit 9ed1e75700bd564968eaae444269f9bd280649a0 Author: Krishnan Mahadevan Date: 2017-10-09T04:05:11Z Support filtering of tests from Base Class (TestNG) User has two test classes 1. An abstract base class called âBaseTestâ which contains an @Test method called âtestMethodFromBaseâ 2. A child class called âChildTestâ which extends âBaseTestâ. User attempts at running the TestNG test via -Dtest=ChildTest#testMethodFromBaseâ. Surefire plugin errors out. Fixed this anomaly for TestNG provider. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins and Maven 3.0.5 or JDK 7
I don't really understand these answers: a demo, please Regards, Hervé Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit : > On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly > > wrote: > > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY wrote: > >> I don't get the technical details > >> but IIUC, you're able to do a PoC with our available git repositories of > >> Jenkins job maintenance (easy job creation + easy Jenkinsfile > >> maintenance), > > > > Job created automatically once there is a git repo with a branch with a > > Jenkinsfile . No human interaction required after `echo > > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git > > commit “add Jenkinsfile” && git push` > > > > Jenkinsfile being just one line `mavenProjectStdBuild` or something like > > that. > > > > Is that easy enough? > > IIRC there is this proposal to let pom modules support directories, pom > locations (these are already supported) and SCM references. Might be > interesting for an aggregator pom. > > Robert > > > and > > > >> you're confident that it can scale to the size we're expecting when > >> we're > >> splitting the current aggregator svn to many small git repos > >> > >> that's it? > >> > >> Regards, > >> > >> Hervé > >> > >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit : > >> > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY > >> > >> wrote: > >> > > TLDR; = > >> > > Perhaps we can start with 2 proofs of concept: > >> > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with > >> > >> 6 > >> > >> > > additional ones in 2 days) > >> > > 2. git split of one of the aggregator svn trunk: skins or > >> > >> doxia-tools > >> can > >> > >> > > be > >> > > easy choices since they are light, where plugins or shared are > >> > >> perhaps > >> too > >> > >> > > heavy. The one working on this PoC will make his choice > >> > > > >> > > then more detailed answer inline that lead to this PoCs proposal > >> > > > >> > > Regards, > >> > > > >> > > Hervé > >> > > > >> > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > >> > > > I don't think the devs would work on all artifacts(projects) a > >> > >> time. > >> > >> > > sure, I think I'm one of the few people working on near everything > >> > >> (with > >> > >> > > rare > >> > > exceptions like Surefire, as you noticed :) ) > >> > > but for usual contributor, there is no issue > >> > > > >> > > I'm not a git expert, then I don't know if easy "full Maven clone" > >> > >> is > >> > >> > > better > >> > > done with a shell script or some git modules > >> > > > >> > > > If the naming convention of repo for a plugin would be artifactId, > >> > >> like > >> > >> > > > /maven-clean-plugin, then even easy to figure out which one to > >> > >> clone. > >> > >> > > > The most likely the dev would just clone one repo she/he is > >> > >> interested > >> > >> > > > in > >> > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > >> > > > It's good to avoid any shared files across them, even I don't > >> > >> think > >> devs > >> > >> > > > share some in svn today. The release process would be quite usual, > >> > >> i.e. > >> > >> > > one > >> > > > >> > > > repo = one project, and new devs already have these experiences > >> > >> which > >> > >> > > will > >> > > > >> > > > be simple for them to adapt faster. > >> > > > >> > > +1 > >> > > the only drawback I see currently is that there is no natural > >> > >> grouping, > >> > >> > > then > >> > > we have a flat lit of near 100 git repos without the current > >> > >> structure > >> > >> > > (plugins, shared components, skins, ...): I think components > >> > >> structure > >> is > >> > >> > > useful for maintenability > >> > > but not really a complete showstopper > >> > > and perhaps the "Maven full clone" tooling can re-create some > >> > >> grouping > >> to > >> > >> > > keep > >> > > visible structure > >> > > > >> > > Now, someone has to know how to create per-component git repo with > >> > >> tags > >> > >> > > (either by reworking exiting git mirrors, either by restarting from > >> > >> svn), > >> > >> > > and > >> > > that's not me :) > >> > > > >> > > given the volume (adding 70 git repos for Maven), we'll have to tell > >> > >> infra > >> > >> > > about it. > >> > > > >> > > Then there is the Jenkins jobs configuration: > >> > > - we need easy Jenkinsfile in each repo > >> > > >> > so we create a shared Groovy library like the Jenkins project does and > >> > >> the > >> > >> > Jenkinsfile becomes `buildPlugin` for all except core > >> > > >> > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > >> > > personally) > >> > > >> > So I will add SCMNavigator functionality to the ASF git-Jenkins plugin > >> > >> and > >> > >> > we just define an org-folder for Maven and all git repos with a > >> > >> Jenkinsfile > >> > >> > will be auto-maintained. > >> > > >
Re: Jenkins and Maven 3.0.5 or JDK 7
On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly wrote: On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY wrote: I don't get the technical details but IIUC, you're able to do a PoC with our available git repositories of Jenkins job maintenance (easy job creation + easy Jenkinsfile maintenance), Job created automatically once there is a git repo with a branch with a Jenkinsfile . No human interaction required after `echo “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git commit “add Jenkinsfile” && git push` Jenkinsfile being just one line `mavenProjectStdBuild` or something like that. Is that easy enough? IIRC there is this proposal to let pom modules support directories, pom locations (these are already supported) and SCM references. Might be interesting for an aggregator pom. Robert and you're confident that it can scale to the size we're expecting when we're splitting the current aggregator svn to many small git repos that's it? Regards, Hervé Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit : > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY wrote: > > TLDR; = > > Perhaps we can start with 2 proofs of concept: > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > > additional ones in 2 days) > > 2. git split of one of the aggregator svn trunk: skins or doxia-tools can > > be > > easy choices since they are light, where plugins or shared are perhaps too > > heavy. The one working on this PoC will make his choice > > > > then more detailed answer inline that lead to this PoCs proposal > > > > Regards, > > > > Hervé > > > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > > I don't think the devs would work on all artifacts(projects) a time. > > > > sure, I think I'm one of the few people working on near everything (with > > rare > > exceptions like Surefire, as you noticed :) ) > > but for usual contributor, there is no issue > > > > I'm not a git expert, then I don't know if easy "full Maven clone" is > > better > > done with a shell script or some git modules > > > > > If the naming convention of repo for a plugin would be artifactId, like > > > /maven-clean-plugin, then even easy to figure out which one to clone. > > > The most likely the dev would just clone one repo she/he is interested > > > in > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > > It's good to avoid any shared files across them, even I don't think devs > > > share some in svn today. The release process would be quite usual, i.e. > > > > one > > > > > repo = one project, and new devs already have these experiences which > > > > will > > > > > be simple for them to adapt faster. > > > > +1 > > the only drawback I see currently is that there is no natural grouping, > > then > > we have a flat lit of near 100 git repos without the current structure > > (plugins, shared components, skins, ...): I think components structure is > > useful for maintenability > > but not really a complete showstopper > > and perhaps the "Maven full clone" tooling can re-create some grouping to > > keep > > visible structure > > > > Now, someone has to know how to create per-component git repo with tags > > (either by reworking exiting git mirrors, either by restarting from svn), > > and > > that's not me :) > > > > given the volume (adding 70 git repos for Maven), we'll have to tell infra > > about it. > > > > Then there is the Jenkins jobs configuration: > > - we need easy Jenkinsfile in each repo > > so we create a shared Groovy library like the Jenkins project does and the > Jenkinsfile becomes `buildPlugin` for all except core > > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > > personally) > > So I will add SCMNavigator functionality to the ASF git-Jenkins plugin and > we just define an org-folder for Maven and all git repos with a Jenkinsfile > will be auto-maintained. > > > And once again, infra will have to be in the loop (at Jenkins side this > > time), > > since I fear the load on Jenkins master node won't be light: perhaps > > that's > > where Jenkins folders will be useful, but I'm not a Jenkins expert either. > > If we use an org folder integrated with GitPubSub I do not think they will > be overly concerned > > > If everything seems feasible to split our svn code into 1 git repo per- > > component, which will bring us to "full Maven code" being near 100 repos, > > I'm > > ok with it. > > We'll need the help of misc experts on Jenkins and git to prepare things > > at > > this scale. > > I think one repo per release root is the way to go. > > We should start by drawing up a list and amalgamation where appropriate: > > Eg > > * does it make sense to release maven-deploy-plugin and > maven-install-plugin independently? Seems we most often make mirroring > changes to both, and perhaps it would be better if we forced that model? > (Don’t answer in
Re: Jenkins and Maven 3.0.5 or JDK 7
On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY wrote: > I don't get the technical details > but IIUC, you're able to do a PoC with our available git repositories of > Jenkins job maintenance (easy job creation + easy Jenkinsfile maintenance), Job created automatically once there is a git repo with a branch with a Jenkinsfile . No human interaction required after `echo “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git commit “add Jenkinsfile” && git push` Jenkinsfile being just one line `mavenProjectStdBuild` or something like that. Is that easy enough? and > you're confident that it can scale to the size we're expecting when we're > splitting the current aggregator svn to many small git repos > > that's it? > > Regards, > > Hervé > > Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit : > > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY wrote: > > > TLDR; = > > > Perhaps we can start with 2 proofs of concept: > > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > > > additional ones in 2 days) > > > 2. git split of one of the aggregator svn trunk: skins or doxia-tools > can > > > be > > > easy choices since they are light, where plugins or shared are perhaps > too > > > heavy. The one working on this PoC will make his choice > > > > > > then more detailed answer inline that lead to this PoCs proposal > > > > > > Regards, > > > > > > Hervé > > > > > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > > > I don't think the devs would work on all artifacts(projects) a time. > > > > > > sure, I think I'm one of the few people working on near everything > (with > > > rare > > > exceptions like Surefire, as you noticed :) ) > > > but for usual contributor, there is no issue > > > > > > I'm not a git expert, then I don't know if easy "full Maven clone" is > > > better > > > done with a shell script or some git modules > > > > > > > If the naming convention of repo for a plugin would be artifactId, > like > > > > /maven-clean-plugin, then even easy to figure out which one to clone. > > > > The most likely the dev would just clone one repo she/he is > interested > > > > in > > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > > > It's good to avoid any shared files across them, even I don't think > devs > > > > share some in svn today. The release process would be quite usual, > i.e. > > > > > > one > > > > > > > repo = one project, and new devs already have these experiences which > > > > > > will > > > > > > > be simple for them to adapt faster. > > > > > > +1 > > > the only drawback I see currently is that there is no natural grouping, > > > then > > > we have a flat lit of near 100 git repos without the current structure > > > (plugins, shared components, skins, ...): I think components structure > is > > > useful for maintenability > > > but not really a complete showstopper > > > and perhaps the "Maven full clone" tooling can re-create some grouping > to > > > keep > > > visible structure > > > > > > Now, someone has to know how to create per-component git repo with tags > > > (either by reworking exiting git mirrors, either by restarting from > svn), > > > and > > > that's not me :) > > > > > > given the volume (adding 70 git repos for Maven), we'll have to tell > infra > > > about it. > > > > > > Then there is the Jenkins jobs configuration: > > > - we need easy Jenkinsfile in each repo > > > > so we create a shared Groovy library like the Jenkins project does and > the > > Jenkinsfile becomes `buildPlugin` for all except core > > > > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > > > personally) > > > > So I will add SCMNavigator functionality to the ASF git-Jenkins plugin > and > > we just define an org-folder for Maven and all git repos with a > Jenkinsfile > > will be auto-maintained. > > > > > And once again, infra will have to be in the loop (at Jenkins side this > > > time), > > > since I fear the load on Jenkins master node won't be light: perhaps > > > that's > > > where Jenkins folders will be useful, but I'm not a Jenkins expert > either. > > > > If we use an org folder integrated with GitPubSub I do not think they > will > > be overly concerned > > > > > If everything seems feasible to split our svn code into 1 git repo per- > > > component, which will bring us to "full Maven code" being near 100 > repos, > > > I'm > > > ok with it. > > > We'll need the help of misc experts on Jenkins and git to prepare > things > > > at > > > this scale. > > > > I think one repo per release root is the way to go. > > > > We should start by drawing up a list and amalgamation where appropriate: > > > > Eg > > > > * does it make sense to release maven-deploy-plugin and > > maven-install-plugin independently? Seems we most often make mirroring > > changes to both, and perhaps it would be better if we forced that model? > > (Don’t answer in this thread, just pointing out an example) > > > > > -
Re: Jenkins and Maven 3.0.5 or JDK 7
any git expert available to tell us if submodules are what we're looking for? And will permit something like svn trunks [1], ie use each submodule to commit independantly, while having easy full code clone or pull. IIUC, we'll have to learn new git commands, since it's not as transparent as svn externals and to have plugins/ and shared/ directories, are we able to have a submodule name with a /, or will we need to create plugins.git and shared.git containing submodules for each component, then reference these repos from the global git repo listing sub modules? once again, a personal git repo on github having submodules to existing maven got repos could make a good PoC: I'm working on m-pdf-p currently, so maybe someone can beat me at it... Regards, Hervé [1] http://svn.apache.org/viewvc/maven/trunks/ Le dimanche 8 octobre 2017, 13:09:58 CEST Tibor Digana a écrit : > Now I have found out that GitHub has submodules. This does not introduce an > intermediate path in URL but it would introduce a kind of groupper repo > folder. For instance maven-clean-plugin would be submodule inside repo > maven-plugins. > References: > https://stackoverflow.com/questions/35043733/how-do-i-create-nested-reposito > ries-in-github > > Example from stackoveflow: > https://github.com/laristra/cinch-nested-example/ > See the definition of submodules > https://github.com/laristra/cinch-nested-example/blob/master/.gitmodules > which results in repos: > https://github.com/laristra/cinch-example/ > https://github.com/laristra/cinch > > I think GitHub does not provide us with better solutions. > > On Sun, Oct 8, 2017 at 12:49 PM, Hervé BOUTEMY > > wrote: > > I fear this is not an option today, but ideally, that would be a perfectly > > visible grouping > > > > we need to find another way of grouping, for people who do care about > > Maven > > general structure: people who just work on an artifact just don't care > > and they don't care that git repos are flat even at Apache level: Apache > > level > > just enforce grouping via repo name prefix > > http://git.apache.org/ > > > > currently, I hope that our "full Maven source code clone" implementation > > would > > make the Maven code structure grouping visible > > if we implement it as a shell script, that's only a few mkdirs: but I'm > > not > > convinced by shell script implementation, since cloning is one command, > > but we > > need also to be able to fetch and pull > > > > Regards, > > > > Hervé > > > > Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit : > > > Would we need to have the URLs like these? > > > github/apache/***/repo > > > https://github.com/apache/*maven-plugins*/maven-clean-plugin/ > > > https://github.com/apache/*maven-shared*/maven-shared-utils/ > > > > > > On Sun, Oct 8, 2017 at 4:55 AM, Hervé BOUTEMY > > > > wrote: > > > > TLDR; = > > > > Perhaps we can start with 2 proofs of concept: > > > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > > > > additional ones in 2 days) > > > > 2. git split of one of the aggregator svn trunk: skins or doxia-tools > > > > can > > > > > > be > > > > easy choices since they are light, where plugins or shared are perhaps > > > > too > > > > > > heavy. The one working on this PoC will make his choice > > > > > > > > then more detailed answer inline that lead to this PoCs proposal > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > > > > I don't think the devs would work on all artifacts(projects) a time. > > > > > > > > sure, I think I'm one of the few people working on near everything > > > > (with > > > > > > rare > > > > exceptions like Surefire, as you noticed :) ) > > > > but for usual contributor, there is no issue > > > > > > > > I'm not a git expert, then I don't know if easy "full Maven clone" is > > > > better > > > > done with a shell script or some git modules > > > > > > > > > If the naming convention of repo for a plugin would be artifactId, > > > > like > > > > > > > /maven-clean-plugin, then even easy to figure out which one to > > > > > clone. > > > > > The most likely the dev would just clone one repo she/he is > > > > interested > > > > > > > in > > > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > > > > It's good to avoid any shared files across them, even I don't think > > > > devs > > > > > > > share some in svn today. The release process would be quite usual, > > > > i.e. > > > > > > one > > > > > > > > > repo = one project, and new devs already have these experiences > > > > > which > > > > > > > > will > > > > > > > > > be simple for them to adapt faster. > > > > > > > > +1 > > > > the only drawback I see currently is that there is no natural > > > > grouping, > > > > then > > > > we have a flat lit of near 100 git repos without the current structure > > > > (plugins, shared components, skins, ...): I think components
Re: Jenkins and Maven 3.0.5 or JDK 7
I don't get the technical details but IIUC, you're able to do a PoC with our available git repositories of Jenkins job maintenance (easy job creation + easy Jenkinsfile maintenance), and you're confident that it can scale to the size we're expecting when we're splitting the current aggregator svn to many small git repos that's it? Regards, Hervé Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit : > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY wrote: > > TLDR; = > > Perhaps we can start with 2 proofs of concept: > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > > additional ones in 2 days) > > 2. git split of one of the aggregator svn trunk: skins or doxia-tools can > > be > > easy choices since they are light, where plugins or shared are perhaps too > > heavy. The one working on this PoC will make his choice > > > > then more detailed answer inline that lead to this PoCs proposal > > > > Regards, > > > > Hervé > > > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > > I don't think the devs would work on all artifacts(projects) a time. > > > > sure, I think I'm one of the few people working on near everything (with > > rare > > exceptions like Surefire, as you noticed :) ) > > but for usual contributor, there is no issue > > > > I'm not a git expert, then I don't know if easy "full Maven clone" is > > better > > done with a shell script or some git modules > > > > > If the naming convention of repo for a plugin would be artifactId, like > > > /maven-clean-plugin, then even easy to figure out which one to clone. > > > The most likely the dev would just clone one repo she/he is interested > > > in > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > > It's good to avoid any shared files across them, even I don't think devs > > > share some in svn today. The release process would be quite usual, i.e. > > > > one > > > > > repo = one project, and new devs already have these experiences which > > > > will > > > > > be simple for them to adapt faster. > > > > +1 > > the only drawback I see currently is that there is no natural grouping, > > then > > we have a flat lit of near 100 git repos without the current structure > > (plugins, shared components, skins, ...): I think components structure is > > useful for maintenability > > but not really a complete showstopper > > and perhaps the "Maven full clone" tooling can re-create some grouping to > > keep > > visible structure > > > > Now, someone has to know how to create per-component git repo with tags > > (either by reworking exiting git mirrors, either by restarting from svn), > > and > > that's not me :) > > > > given the volume (adding 70 git repos for Maven), we'll have to tell infra > > about it. > > > > Then there is the Jenkins jobs configuration: > > - we need easy Jenkinsfile in each repo > > so we create a shared Groovy library like the Jenkins project does and the > Jenkinsfile becomes `buildPlugin` for all except core > > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > > personally) > > So I will add SCMNavigator functionality to the ASF git-Jenkins plugin and > we just define an org-folder for Maven and all git repos with a Jenkinsfile > will be auto-maintained. > > > And once again, infra will have to be in the loop (at Jenkins side this > > time), > > since I fear the load on Jenkins master node won't be light: perhaps > > that's > > where Jenkins folders will be useful, but I'm not a Jenkins expert either. > > If we use an org folder integrated with GitPubSub I do not think they will > be overly concerned > > > If everything seems feasible to split our svn code into 1 git repo per- > > component, which will bring us to "full Maven code" being near 100 repos, > > I'm > > ok with it. > > We'll need the help of misc experts on Jenkins and git to prepare things > > at > > this scale. > > I think one repo per release root is the way to go. > > We should start by drawing up a list and amalgamation where appropriate: > > Eg > > * does it make sense to release maven-deploy-plugin and > maven-install-plugin independently? Seems we most often make mirroring > changes to both, and perhaps it would be better if we forced that model? > (Don’t answer in this thread, just pointing out an example) > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > > Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins and Maven 3.0.5 or JDK 7
On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY wrote: > TLDR; = > Perhaps we can start with 2 proofs of concept: > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > additional ones in 2 days) > 2. git split of one of the aggregator svn trunk: skins or doxia-tools can > be > easy choices since they are light, where plugins or shared are perhaps too > heavy. The one working on this PoC will make his choice > > then more detailed answer inline that lead to this PoCs proposal > > Regards, > > Hervé > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > I don't think the devs would work on all artifacts(projects) a time. > sure, I think I'm one of the few people working on near everything (with > rare > exceptions like Surefire, as you noticed :) ) > but for usual contributor, there is no issue > > I'm not a git expert, then I don't know if easy "full Maven clone" is > better > done with a shell script or some git modules > > > If the naming convention of repo for a plugin would be artifactId, like > > /maven-clean-plugin, then even easy to figure out which one to clone. > > The most likely the dev would just clone one repo she/he is interested in > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > It's good to avoid any shared files across them, even I don't think devs > > share some in svn today. The release process would be quite usual, i.e. > one > > repo = one project, and new devs already have these experiences which > will > > be simple for them to adapt faster. > +1 > the only drawback I see currently is that there is no natural grouping, > then > we have a flat lit of near 100 git repos without the current structure > (plugins, shared components, skins, ...): I think components structure is > useful for maintenability > but not really a complete showstopper > and perhaps the "Maven full clone" tooling can re-create some grouping to > keep > visible structure > > Now, someone has to know how to create per-component git repo with tags > (either by reworking exiting git mirrors, either by restarting from svn), > and > that's not me :) > > given the volume (adding 70 git repos for Maven), we'll have to tell infra > about it. > > Then there is the Jenkins jobs configuration: > - we need easy Jenkinsfile in each repo so we create a shared Groovy library like the Jenkins project does and the Jenkinsfile becomes `buildPlugin` for all except core > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > personally) So I will add SCMNavigator functionality to the ASF git-Jenkins plugin and we just define an org-folder for Maven and all git repos with a Jenkinsfile will be auto-maintained. > > And once again, infra will have to be in the loop (at Jenkins side this > time), > since I fear the load on Jenkins master node won't be light: perhaps that's > where Jenkins folders will be useful, but I'm not a Jenkins expert either. If we use an org folder integrated with GitPubSub I do not think they will be overly concerned > > > If everything seems feasible to split our svn code into 1 git repo per- > component, which will bring us to "full Maven code" being near 100 repos, > I'm > ok with it. > We'll need the help of misc experts on Jenkins and git to prepare things at > this scale. I think one repo per release root is the way to go. We should start by drawing up a list and amalgamation where appropriate: Eg * does it make sense to release maven-deploy-plugin and maven-install-plugin independently? Seems we most often make mirroring changes to both, and perhaps it would be better if we forced that model? (Don’t answer in this thread, just pointing out an example) > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
[ANN] Apache Maven Doxia Sitetools 1.7.5 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Doxia Sitetools, version 1.7.5 Doxia Sitetools is an extension of base Doxia component that generates either HTML sites, consisting of decoration and content that was generated by Doxia, or documents like RTF or PDF. In addition, Doxia Sitetools processes files with extra .vm extension with Velocity. https://maven.apache.org/doxia/doxia-sitetools/index.html You can download the appropriate sources etc. from the download page: https://maven.apache.org/doxia/doxia-sitetools/download.cgi Release Notes - Maven Doxia Sitetools - Version 1.7.5 ** Bug * [DOXIASITETOOLS-172] - Width, height and border values not used for banner display * [DOXIASITETOOLS-173] - Default skin CSS maven-base.css sets border:none on all images with tag img * [DOXIASITETOOLS-175] - change Velocity engine links * [DOXIASITETOOLS-177] - Use of commons-lang 2 causes failure with JDK 9 b175+ ** Improvement * [DOXIASITETOOLS-178] - Upgrade to Commons Lang 3 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Doxia Sitetools version 1.7.5
Hi, The vote has passed with the following result: +1 : Robert Scholte, Michael Osipov, Karl Heinz Marbaise, Hervé BOUTEMY PMC quorum: reached I will promote the artifacts to the central repo. On Tue, 26 Sep 2017 20:51:11 +0200, Robert Scholte wrote: Hi, We solved 5 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320&version=12338982&styleName=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1370/ https://repository.apache.org/content/repositories/maven-1370/org/apache/maven/doxia/doxia-sitetools/1.7.5/doxia-sitetools-1.7.5-source-release.zip Source release checksum(s): doxia-sitetools-1.7.5-source-release.zip sha1: 9ab874120bd60f532c167a430d8e077c2914016d Staging site: https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Le dimanche 8 octobre 2017, 15:37:54 CEST Benedikt Ritter a écrit : > Hello Hervé > > > Then I added a pluginManagement section to select version 3.0.2 and re-ran > > the test: you'll see the output is completely different. > > > > And there is no issue any more > > Thank you so much, you took the time to investigate this issue! Really much > appreciated. Now I wonder, why Maven uses an outdated version of the > dependency plugin. Is this a problem with the super pom? this is a choice to keep stability: if one downloads dependencies using Maven 3.0.5 then a few days later builds offline with Maven 3.5, he does not have any issue (and blame dependency-plugin) remember the good practice: define your plugin versions, either in your pom or by using a parent that does the job > > Furthermore I’ve noticed, that mvn -o test still does not work, because some > surefire dependencies are missing: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) > on project dependency-plugin-bug: Unable to generate classpath: > org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: [ERROR] -- > [ERROR] 1) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 > [ERROR] > [ERROR] Try downloading the file manually from the project website. > [ERROR] > [ERROR] Then, install it using the command: > [ERROR] mvn install:install-file -DgroupId=org.apache.maven.surefire > -DartifactId=surefire-junit3 -Dversion=2.12.4 -Dpackaging=jar > -Dfile=/path/to/file [ERROR] > [ERROR] Alternatively, if you host your own repository you can deploy the > file there: [ERROR] mvn deploy:deploy-file > -DgroupId=org.apache.maven.surefire -DartifactId=surefire-junit3 > -Dversion=2.12.4 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] > -DrepositoryId=[id] [ERROR] > [ERROR] Path to dependency: > [ERROR] 1) dummy:dummy:jar:1.0 > [ERROR] 2) org.apache.maven.surefire:surefire-junit3:jar:2.12.4 > [ERROR] > [ERROR] -- > [ERROR] 1 required artifact is missing. > [ERROR] > [ERROR] for artifact: > [ERROR] dummy:dummy:jar:1.0 > [ERROR] > [ERROR] from the specified remote repositories: > [ERROR] central (https://repo.maven.apache.org/maven2, releases=true, > snapshots=false) [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. [ERROR] Re-run Maven using the -X switch to enable full debug > logging. [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > > Since there are only a few dependencies missing, I will run test not in > offline modus on my CI server. But I wonder whether this is a bug. I'll have a look at this one and report Regards, Hervé > > Regards, > Benedikt > > > Regards, > > > > Hervé > > > > Le mercredi 20 septembre 2017, 22:48:15 CEST Benedikt Ritter a écrit : > >> Hi, > >> > >> as far as I understand it should be possible to call mvn > >> dependency:go-offline and from there on work in offline mode (mvn -o). > >> I’ve put a minimal example together [1] that demonstrates that this > >> currently does not work. Am I missing anything? > >> > >> Thank you! > >> Benedikt > >> > >> [1] https://github.com/britter/dependency-plugin-bug > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Surefire and JUnit 5
Hello Tibor > Am 06.10.2017 um 01:18 schrieb Tibor Digana : > > Hi Benedikt, > > Would you agree with this plan. > Since we try to release version 2.21.0 with Jigsaw modularity which is Java 9 > related feature, we can make the same compromise with JUnit5 in next version > 2.22.0. Altough Surifire is compiled with javac -source 1.6 -target 1.6, and > JUnit 5/Java 1.8 provider is standalone jar file which does not force the > plugin itself to load Java 8 classes from the provider, we can freely work on > JUnit 5 provider after the version 2.21.0.Jigsaw has been released. I guess I > will start the release Vote next week and then we can pickup your commits > from the branch junit5, squash them into one single commit and rebase on the > top of future master/HEAD. > I believe you want to merge some more fixes from JUnit team afterwards and > maybe to add some more tests. > > What do you think, would it be possible for you? This would be so great! I’m currently really blocked by the fact, that I can’t run the surefire build without errors. If you could help fix this, maybe by rebasing everything, this would be very much appreciated. Looking forward to hearing from you! Regards, Benedikt > > Cheers > Tibor > > On Sun, Oct 1, 2017 at 5:12 PM, Enrico Olivelli wrote: > Sorry > I wanted to reply to another message from Benedikt > Enrico > > Il dom 1 ott 2017, 16:17 Karl Heinz Marbaise ha scritto: > > > Hi Enrico, > > > > On 01/10/17 16:00, Enrico Olivelli wrote: > > > Benedikt, > > > did you try to update all of your maven plugins to latest version? > > > Can you share some stacktrace? This will give a first hint without having > > > to build jUDDI > > > > This is the wrong mailing list...Users list was the subject about jUDDI > > ;-).. > > > > Not related to Surefire and JUnit 5 ... > > > > Kind regards > > Karl Heinz Marbaise > > > Cheers > > > > > > Enrico > > > > > > Il sab 30 set 2017, 10:34 Benedikt Ritter ha > > scritto: > > > > > >> Hello, > > >> > > >> for over a year now I’m trying to help getting JUnit 5 support into > > Maven > > >> Surefire. This has been hard since Tibor seems to be the only one > > >> maintaining Maven Surefire and he had to come with other things. > > >> > > >> For this reason I’d like to ask other Maven maintainers to help with the > > >> JUnit 5 support. I’m happy to do the work, but I’m constantly blocked by > > >> obscure build failures which I’m unable to resolve myself or by lack of > > >> code review und merge of changes. > > >> > > >> - Work on JUnit5 support is currently done in the junit5 branch. > > >> - I have drafted a Provider Lookup implementation in the junit5 branch, > > >> but I don’t know whether it works because I can’t get the integration > > tests > > >> running > > >> - There is an open PR to merge the master branch back into junit5 > > branch, > > >> but it has build failures I don’t understand [1] > > >> > > >> Please help! > > >> Cheers, > > >> Benedikt > > > -- > > > -- Enrico Olivelli > > > > -- > Cheers > Tibor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: dependency:go-offline broken?
Hello Hervé
> Am 04.10.2017 um 01:01 schrieb Hervé BOUTEMY :
>
> trying my chance, because you prepared a perfect demo then we should be able
> to find where the issue is...
>
> Here are my findings:
> mvn depencendy:go-offline output for maven-resources-plugin:
>
> [INFO] Plugin Resolved: maven-resources-plugin-2.6.jar
> [INFO] Plugin Dependency Resolved: maven-plugin-api-2.0.6.jar
> [INFO] Plugin Dependency Resolved: maven-project-2.0.6.jar
> [INFO] Plugin Dependency Resolved: maven-core-2.0.6.jar
> [INFO] Plugin Dependency Resolved: maven-artifact-2.0.6.jar
> [INFO] Plugin Dependency Resolved: maven-settings-2.0.6.jar
> [INFO] Plugin Dependency Resolved: maven-model-2.0.6.jar
> [INFO] Plugin Dependency Resolved: maven-monitor-2.0.6.jar
> [INFO] Plugin Dependency Resolved: plexus-container-default-1.0-alpha-9-
> stable-1.jar
> [INFO] Plugin Dependency Resolved: plexus-utils-2.0.5.jar
> [INFO] Plugin Dependency Resolved: maven-filtering-1.1.jar
> [INFO] Plugin Dependency Resolved: plexus-interpolation-1.13.jar
>
>
> then on the failure: mvn -X -o compile
>
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> dependency-plugin-bug ---
> [DEBUG] Using mirror central (http://localhost:8081/nexus/content/groups/
> public) for central (http://repo1.maven.org/maven2).
> [WARNING] The POM for org.apache.maven:maven-core:jar:2.0.6 is missing, no
> dependency information available
> [WARNING] The POM for org.apache.maven:maven-monitor:jar:2.0.6 is missing, no
> dependency information available
> [WARNING] The POM for org.codehaus.plexus:plexus-utils:jar:2.0.5 is missing,
> no dependency information available
> [WARNING] The POM for org.apache.maven.shared:maven-filtering:jar:1.1 is
> missing, no dependency information available
> [WARNING] The POM for org.codehaus.plexus:plexus-interpolation:jar:1.13 is
> missing, no dependency information available
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
> ConflictMarker.markTime=0, ConflictMarker.nodeCount=41,
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0,
> ConflictIdSorter.conflictIdCount=18, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=1, ConflictResolver.conflictItemCount=38,
> DefaultDependencyCollector.collectTime=58,
> DefaultDependencyCollector.transformTime=1}
> [DEBUG] org.apache.maven.plugins:maven-resources-plugin:jar:2.6:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:2.0.6:compile
> [DEBUG]org.apache.maven:maven-project:jar:2.0.6:compile
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.6:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.6:compile
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.6:compile
> [DEBUG] org.apache.maven:maven-plugin-registry:jar:2.0.6:compile
> [DEBUG]org.apache.maven:maven-core:jar:2.0.6:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:2.0.6:compile
> [DEBUG]org.apache.maven:maven-settings:jar:2.0.6:compile
> [DEBUG]org.apache.maven:maven-model:jar:2.0.6:compile
> [DEBUG]org.apache.maven:maven-monitor:jar:2.0.6:compile
> [DEBUG]org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-
> stable-1:compile
> [DEBUG] junit:junit:jar:3.8.1:compile
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:2.0.5:compile
> [DEBUG]org.apache.maven.shared:maven-filtering:jar:1.1:compile
> [DEBUG]org.codehaus.plexus:plexus-interpolation:jar:1.13:compile
>
>
> As you can see, the missing files maven-profile-2.0.6.jar, maven-artifact-
> manager-2.0.6.jar, maven-repository-metadata-2.0.6.jar, maven-plugin-
> registry-2.0.6.jar and classworlds-1.1-alpha-2.jar are in the maven-resources-
> plugin effective dependencies but not detected by dependency plugin
>
>
> Then you're right, it's a dependency plugin bug.
>
> I remarked that the plugin version used was 2.8 but not the latest 3.0.2
>
> Then I added a pluginManagement section to select version 3.0.2 and re-ran
> the
> test: you'll see the output is completely different.
>
> And there is no issue any more
Thank you so much, you took the time to investigate this issue! Really much
appreciated. Now I wonder, why Maven uses an outdated version of the dependency
plugin. Is this a problem with the super pom?
Furthermore I’ve noticed, that mvn -o test still does not work, because some
surefire dependencies are missing:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on
project dependency-plugin-bug: Unable to generate classpath:
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
[ERROR] --
[ERROR] 1) org.apache.maven.surefire:surefire-junit3:jar:2.12.4
[ERROR]
[ERROR] Try downloading the file manually from the project website.
[ERROR]
[ERROR] Then, install it using the command:
[E
[ANN] Apache Maven WAR Plugin Version 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven WAR Plugin, version 3.2.0. The WAR Plugin is responsible for collecting all artifact dependencies, classes and resources of the web application and packaging them into a web application archive. http://maven.apache.org/plugins/maven-war-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-war-plugin 3.2.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-war-plugin/download.cgi Important Note: * Maven 3.X only * JDK 7 minimum requirement Release Notes - Maven WAR Plugin - Version 3.2.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121&version=12341372 Bug: * [MWAR-407] - Binary files are modified during web.xml filtering; revert MWAR-404 Dependency upgrades: * [MWAR-409] - Upgrade maven-archiver to 3.2.0 / plexus-archiver 3.5 * [MWAR-410] - Upgrade plexus-utils to version 3.1.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins and Maven 3.0.5 or JDK 7
Now I have found out that GitHub has submodules. This does not introduce an intermediate path in URL but it would introduce a kind of groupper repo folder. For instance maven-clean-plugin would be submodule inside repo maven-plugins. References: https://stackoverflow.com/questions/35043733/how-do-i-create-nested-repositories-in-github Example from stackoveflow: https://github.com/laristra/cinch-nested-example/ See the definition of submodules https://github.com/laristra/cinch-nested-example/blob/master/.gitmodules which results in repos: https://github.com/laristra/cinch-example/ https://github.com/laristra/cinch I think GitHub does not provide us with better solutions. On Sun, Oct 8, 2017 at 12:49 PM, Hervé BOUTEMY wrote: > I fear this is not an option today, but ideally, that would be a perfectly > visible grouping > > we need to find another way of grouping, for people who do care about Maven > general structure: people who just work on an artifact just don't care > and they don't care that git repos are flat even at Apache level: Apache > level > just enforce grouping via repo name prefix > http://git.apache.org/ > > currently, I hope that our "full Maven source code clone" implementation > would > make the Maven code structure grouping visible > if we implement it as a shell script, that's only a few mkdirs: but I'm not > convinced by shell script implementation, since cloning is one command, > but we > need also to be able to fetch and pull > > Regards, > > Hervé > > Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit : > > Would we need to have the URLs like these? > > github/apache/***/repo > > https://github.com/apache/*maven-plugins*/maven-clean-plugin/ > > https://github.com/apache/*maven-shared*/maven-shared-utils/ > > > > On Sun, Oct 8, 2017 at 4:55 AM, Hervé BOUTEMY > wrote: > > > TLDR; = > > > Perhaps we can start with 2 proofs of concept: > > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > > > additional ones in 2 days) > > > 2. git split of one of the aggregator svn trunk: skins or doxia-tools > can > > > be > > > easy choices since they are light, where plugins or shared are perhaps > too > > > heavy. The one working on this PoC will make his choice > > > > > > then more detailed answer inline that lead to this PoCs proposal > > > > > > Regards, > > > > > > Hervé > > > > > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > > > I don't think the devs would work on all artifacts(projects) a time. > > > > > > sure, I think I'm one of the few people working on near everything > (with > > > rare > > > exceptions like Surefire, as you noticed :) ) > > > but for usual contributor, there is no issue > > > > > > I'm not a git expert, then I don't know if easy "full Maven clone" is > > > better > > > done with a shell script or some git modules > > > > > > > If the naming convention of repo for a plugin would be artifactId, > like > > > > /maven-clean-plugin, then even easy to figure out which one to clone. > > > > The most likely the dev would just clone one repo she/he is > interested > > > > in > > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > > > It's good to avoid any shared files across them, even I don't think > devs > > > > share some in svn today. The release process would be quite usual, > i.e. > > > > > > one > > > > > > > repo = one project, and new devs already have these experiences which > > > > > > will > > > > > > > be simple for them to adapt faster. > > > > > > +1 > > > the only drawback I see currently is that there is no natural grouping, > > > then > > > we have a flat lit of near 100 git repos without the current structure > > > (plugins, shared components, skins, ...): I think components structure > is > > > useful for maintenability > > > but not really a complete showstopper > > > and perhaps the "Maven full clone" tooling can re-create some grouping > to > > > keep > > > visible structure > > > > > > Now, someone has to know how to create per-component git repo with tags > > > (either by reworking exiting git mirrors, either by restarting from > svn), > > > and > > > that's not me :) > > > > > > given the volume (adding 70 git repos for Maven), we'll have to tell > infra > > > about it. > > > > > > Then there is the Jenkins jobs configuration: > > > - we need easy Jenkinsfile in each repo > > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > > > personally) > > > And once again, infra will have to be in the loop (at Jenkins side this > > > time), > > > since I fear the load on Jenkins master node won't be light: perhaps > > > that's > > > where Jenkins folders will be useful, but I'm not a Jenkins expert > either. > > > > > > > > > If everything seems feasible to split our svn code into 1 git repo per- > > > component, which will bring us to "full Maven code" being near 100 > repos, > > > I'm > > > ok with it. > > > We'll need the help of misc experts on Jenkins
Re: Jenkins and Maven 3.0.5 or JDK 7
I fear this is not an option today, but ideally, that would be a perfectly visible grouping we need to find another way of grouping, for people who do care about Maven general structure: people who just work on an artifact just don't care and they don't care that git repos are flat even at Apache level: Apache level just enforce grouping via repo name prefix http://git.apache.org/ currently, I hope that our "full Maven source code clone" implementation would make the Maven code structure grouping visible if we implement it as a shell script, that's only a few mkdirs: but I'm not convinced by shell script implementation, since cloning is one command, but we need also to be able to fetch and pull Regards, Hervé Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit : > Would we need to have the URLs like these? > github/apache/***/repo > https://github.com/apache/*maven-plugins*/maven-clean-plugin/ > https://github.com/apache/*maven-shared*/maven-shared-utils/ > > On Sun, Oct 8, 2017 at 4:55 AM, Hervé BOUTEMY wrote: > > TLDR; = > > Perhaps we can start with 2 proofs of concept: > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > > additional ones in 2 days) > > 2. git split of one of the aggregator svn trunk: skins or doxia-tools can > > be > > easy choices since they are light, where plugins or shared are perhaps too > > heavy. The one working on this PoC will make his choice > > > > then more detailed answer inline that lead to this PoCs proposal > > > > Regards, > > > > Hervé > > > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > > I don't think the devs would work on all artifacts(projects) a time. > > > > sure, I think I'm one of the few people working on near everything (with > > rare > > exceptions like Surefire, as you noticed :) ) > > but for usual contributor, there is no issue > > > > I'm not a git expert, then I don't know if easy "full Maven clone" is > > better > > done with a shell script or some git modules > > > > > If the naming convention of repo for a plugin would be artifactId, like > > > /maven-clean-plugin, then even easy to figure out which one to clone. > > > The most likely the dev would just clone one repo she/he is interested > > > in > > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > > It's good to avoid any shared files across them, even I don't think devs > > > share some in svn today. The release process would be quite usual, i.e. > > > > one > > > > > repo = one project, and new devs already have these experiences which > > > > will > > > > > be simple for them to adapt faster. > > > > +1 > > the only drawback I see currently is that there is no natural grouping, > > then > > we have a flat lit of near 100 git repos without the current structure > > (plugins, shared components, skins, ...): I think components structure is > > useful for maintenability > > but not really a complete showstopper > > and perhaps the "Maven full clone" tooling can re-create some grouping to > > keep > > visible structure > > > > Now, someone has to know how to create per-component git repo with tags > > (either by reworking exiting git mirrors, either by restarting from svn), > > and > > that's not me :) > > > > given the volume (adding 70 git repos for Maven), we'll have to tell infra > > about it. > > > > Then there is the Jenkins jobs configuration: > > - we need easy Jenkinsfile in each repo > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > > personally) > > And once again, infra will have to be in the loop (at Jenkins side this > > time), > > since I fear the load on Jenkins master node won't be light: perhaps > > that's > > where Jenkins folders will be useful, but I'm not a Jenkins expert either. > > > > > > If everything seems feasible to split our svn code into 1 git repo per- > > component, which will bring us to "full Maven code" being near 100 repos, > > I'm > > ok with it. > > We'll need the help of misc experts on Jenkins and git to prepare things > > at > > this scale. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins and Maven 3.0.5 or JDK 7
Would we need to have the URLs like these? github/apache/***/repo https://github.com/apache/*maven-plugins*/maven-clean-plugin/ https://github.com/apache/*maven-shared*/maven-shared-utils/ On Sun, Oct 8, 2017 at 4:55 AM, Hervé BOUTEMY wrote: > TLDR; = > Perhaps we can start with 2 proofs of concept: > 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 > additional ones in 2 days) > 2. git split of one of the aggregator svn trunk: skins or doxia-tools can > be > easy choices since they are light, where plugins or shared are perhaps too > heavy. The one working on this PoC will make his choice > > then more detailed answer inline that lead to this PoCs proposal > > Regards, > > Hervé > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > > I don't think the devs would work on all artifacts(projects) a time. > sure, I think I'm one of the few people working on near everything (with > rare > exceptions like Surefire, as you noticed :) ) > but for usual contributor, there is no issue > > I'm not a git expert, then I don't know if easy "full Maven clone" is > better > done with a shell script or some git modules > > > If the naming convention of repo for a plugin would be artifactId, like > > /maven-clean-plugin, then even easy to figure out which one to clone. > > The most likely the dev would just clone one repo she/he is interested in > > at the moment, i.e. repository /maven-clean-plugin, let's say. > > It's good to avoid any shared files across them, even I don't think devs > > share some in svn today. The release process would be quite usual, i.e. > one > > repo = one project, and new devs already have these experiences which > will > > be simple for them to adapt faster. > +1 > the only drawback I see currently is that there is no natural grouping, > then > we have a flat lit of near 100 git repos without the current structure > (plugins, shared components, skins, ...): I think components structure is > useful for maintenability > but not really a complete showstopper > and perhaps the "Maven full clone" tooling can re-create some grouping to > keep > visible structure > > Now, someone has to know how to create per-component git repo with tags > (either by reworking exiting git mirrors, either by restarting from svn), > and > that's not me :) > > given the volume (adding 70 git repos for Maven), we'll have to tell infra > about it. > > Then there is the Jenkins jobs configuration: > - we need easy Jenkinsfile in each repo > - we need easy 80 jobs creation (no, I won't manually create 80 jobs > personally) > And once again, infra will have to be in the loop (at Jenkins side this > time), > since I fear the load on Jenkins master node won't be light: perhaps that's > where Jenkins folders will be useful, but I'm not a Jenkins expert either. > > > If everything seems feasible to split our svn code into 1 git repo per- > component, which will bring us to "full Maven code" being near 100 repos, > I'm > ok with it. > We'll need the help of misc experts on Jenkins and git to prepare things at > this scale. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
