Re: How secure is invoking a single mojo?
Tamas, Thanks for your idea. If I wanted to resolve from reading a pom file from scratch, where you'd point me at (thinking MavenXpp3Reader and friends perhaps?). -- -- Aldrin Leal, / https://aldrinleal.link On Fri, Dec 16, 2022 at 4:17 PM Tamás Cservenák wrote: > You can write a simple app, using resolver. There are demo that perform > fully functional things, for example > > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples/GetDependencyTree.java > > Hth > T > > On Fri, Dec 16, 2022, 22:12 Aldrin Leal wrote: > > > Thanks Michael, indeed this can be better worded What about? > > > > How to programatically list a poms dependencies (incl transitive) without > > the risk of running untrusted/unauthorized code? > > > > -- > > -- Aldrin Leal, / https://aldrinleal.link > > > > > > On Fri, Dec 16, 2022 at 3:55 PM Michael Osipov > > wrote: > > > > > Am 2022-12-16 um 18:02 schrieb Aldrin Leal: > > > > Hello, > > > > > > > > Just a question I'd like to confirm with you guys: How "safe" is to > run > > > > `dependency:tree` on a given arbitrary pom? > > > > > > > > I mean, whats the likelihood of that pom.xml triggering some "unsafe" > > > code? > > > > > > > > And how would you do this in (listing all the required runtime jar > > files > > > > for a given project) the most secure way if you were given this task? > > > > > > Safety and security are two different things. What are you striving > for? > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
Re: How secure is invoking a single mojo?
Thanks Michael, indeed this can be better worded What about? How to programatically list a poms dependencies (incl transitive) without the risk of running untrusted/unauthorized code? -- -- Aldrin Leal, / https://aldrinleal.link On Fri, Dec 16, 2022 at 3:55 PM Michael Osipov wrote: > Am 2022-12-16 um 18:02 schrieb Aldrin Leal: > > Hello, > > > > Just a question I'd like to confirm with you guys: How "safe" is to run > > `dependency:tree` on a given arbitrary pom? > > > > I mean, whats the likelihood of that pom.xml triggering some "unsafe" > code? > > > > And how would you do this in (listing all the required runtime jar files > > for a given project) the most secure way if you were given this task? > > Safety and security are two different things. What are you striving for? > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
How secure is invoking a single mojo?
Hello, Just a question I'd like to confirm with you guys: How "safe" is to run `dependency:tree` on a given arbitrary pom? I mean, whats the likelihood of that pom.xml triggering some "unsafe" code? And how would you do this in (listing all the required runtime jar files for a given project) the most secure way if you were given this task? Thank you -- -- Aldrin Leal, / https://aldrinleal.link
Re: Silly Saturday idea - If Maven Central were a bunch of Git repos
thats my point: the golang approach does no magic at all. It simply stores the source code and bases it on a convention. Just the files, and thats it. -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Wed, May 17, 2017 at 2:38 PM, Paul Hammant <p...@hammant.org> wrote: > Aldrin, The blog entry I wrote on saturday mulled classes, javadocs and > sources - > https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/ > (re > your "way more than" comment). > > The GH repo I linked you to earlier has all three in one repo (see the > branches drop-down) - https://github.com/paul-hammant/mc-xs-all > > - Paul > > > > On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <ald...@leal.eng.br> wrote: > > > I understand the approach is basically general, but maven artifacts are > way > > more than binary code (there's source and javadoc). I also understand its > > an interesting option for distribution. > > > > I really would like to see something close to what "go get" does. If not > > github and bitbucket (and go get includes git, hg and bzr among scms), it > > open the URL itself and resolve it into a(by means of HTML metadata). > > > > Just distributing the source allowing it to easily updates would be > > awesome, since it would allow less effort to create and distribute. Of > > course, we could have to limit the scope of what to do to avoid abuse. > > > > > > -- > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <p...@hammant.org> wrote: > > > > > There is that, yes. And Git's general upper limits which are subject of > > "I > > > heard of a team that had a corruption at 2GB". I've field tested Git > up > > to > > > 7GB for a git-svn-clone myself (a team considering saying bye bye to > > Svn), > > > but wouldn't put that live versus hive off history to a R/O repo, and > > start > > > over with HEAD of the old becoming the initial commit of the new. > > > > > > - Paul > > > > > > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <ald...@leal.eng.br> > wrote: > > > > > > > Still, once github gets an outage, our repositories are basically > > > > 'left-padded' (taken offline) > > > > > > > > -- > > > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > > > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> > > wrote: > > > > > > > > > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large > files > > > > added > > > > > to Git. Git makes 70% saving on bytes used ('bare' mode). > > > > > > > > > > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> > > > > wrote: > > > > > > > > > > > Just a friendly reminder that git is not optimized for large > files > > > (for > > > > > > this, they made git-lfs). Plus, when you do checkout a git repo, > > > > there's > > > > > no > > > > > > binary diffs - so if you've got plenty of releases, you'll be > > > wasting a > > > > > lot > > > > > > of space/time in terms of transmission and storage. > > > > > > > > > > > > -- > > > > > > -- Aldrin Leal, <ald...@leal.eng.br> / > http://about.me/aldrinleal > > > > > > > > > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> > > > > wrote: > > > > > > > > > > > > > We can agree to differ on what I'm suggesting and what the > impact > > > of > > > > > that > > > > > > > would be :) > > > > > > > > > > > > > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu > > > > > > wrote: > > > > > > > > > > > > > > > Even more than redefining what Central does, you're > effectively > > > > > > > describing > > > > > > > > a new, unofficial java class packaging and distribution > > > mechanism. > > > > > This > > > > > > > > seems like it will violate signatures etc and make tracking > of > > > what > > > > > you > >
Re: Silly Saturday idea - If Maven Central were a bunch of Git repos
I understand the approach is basically general, but maven artifacts are way more than binary code (there's source and javadoc). I also understand its an interesting option for distribution. I really would like to see something close to what "go get" does. If not github and bitbucket (and go get includes git, hg and bzr among scms), it open the URL itself and resolve it into a(by means of HTML metadata). Just distributing the source allowing it to easily updates would be awesome, since it would allow less effort to create and distribute. Of course, we could have to limit the scope of what to do to avoid abuse. -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Wed, May 17, 2017 at 1:49 PM, Paul Hammant <p...@hammant.org> wrote: > There is that, yes. And Git's general upper limits which are subject of "I > heard of a team that had a corruption at 2GB". I've field tested Git up to > 7GB for a git-svn-clone myself (a team considering saying bye bye to Svn), > but wouldn't put that live versus hive off history to a R/O repo, and start > over with HEAD of the old becoming the initial commit of the new. > > - Paul > > On Wed, May 17, 2017 at 2:40 PM, Aldrin Leal <ald...@leal.eng.br> wrote: > > > Still, once github gets an outage, our repositories are basically > > 'left-padded' (taken offline) > > > > -- > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> wrote: > > > > > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files > > added > > > to Git. Git makes 70% saving on bytes used ('bare' mode). > > > > > > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> > > wrote: > > > > > > > Just a friendly reminder that git is not optimized for large files > (for > > > > this, they made git-lfs). Plus, when you do checkout a git repo, > > there's > > > no > > > > binary diffs - so if you've got plenty of releases, you'll be > wasting a > > > lot > > > > of space/time in terms of transmission and storage. > > > > > > > > -- > > > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> > > wrote: > > > > > > > > > We can agree to differ on what I'm suggesting and what the impact > of > > > that > > > > > would be :) > > > > > > > > > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> > > wrote: > > > > > > > > > > > Even more than redefining what Central does, you're effectively > > > > > describing > > > > > > a new, unofficial java class packaging and distribution > mechanism. > > > This > > > > > > seems like it will violate signatures etc and make tracking of > what > > > you > > > > > > actually have a nightmare. > > > > > > > > > > > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY < > > > herve.bout...@free.fr> > > > > > > wrote: > > > > > > > > > > > > > this idea of putting everything in git is funny: not sure this > > will > > > > go > > > > > > very > > > > > > > far from this poc, but let's imagine... > > > > > > > > > > > > > > on classes branch, splitting the jar into individual .class has > > > IMHO > > > > a > > > > > > big > > > > > > > drawback: we loose original jar and its signature > > > > > > > > > > > > > > On the other branches, the current poc shows commits for > versions > > > > that > > > > > > are > > > > > > > perfectly linear: if there are multiple branches that are > > released > > > in > > > > > > > parallel, the commit won't be so clean. I don't know if this > will > > > > have > > > > > an > > > > > > > impact on compression efficiency. > > > > > > > > > > > > > > Another issue with this idea: during development, with > SNAPSHOTs, > > > the > > > > > git > > > > > > > repo > > > > > > > will be polluted: this idea IMHO co
Re: Silly Saturday idea - If Maven Central were a bunch of Git repos
Still, once github gets an outage, our repositories are basically 'left-padded' (taken offline) -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> wrote: > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files added > to Git. Git makes 70% saving on bytes used ('bare' mode). > > On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> wrote: > > > Just a friendly reminder that git is not optimized for large files (for > > this, they made git-lfs). Plus, when you do checkout a git repo, there's > no > > binary diffs - so if you've got plenty of releases, you'll be wasting a > lot > > of space/time in terms of transmission and storage. > > > > -- > > -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal > > > > On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> wrote: > > > > > We can agree to differ on what I'm suggesting and what the impact of > that > > > would be :) > > > > > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote: > > > > > > > Even more than redefining what Central does, you're effectively > > > describing > > > > a new, unofficial java class packaging and distribution mechanism. > This > > > > seems like it will violate signatures etc and make tracking of what > you > > > > actually have a nightmare. > > > > > > > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY < > herve.bout...@free.fr> > > > > wrote: > > > > > > > > > this idea of putting everything in git is funny: not sure this will > > go > > > > very > > > > > far from this poc, but let's imagine... > > > > > > > > > > on classes branch, splitting the jar into individual .class has > IMHO > > a > > > > big > > > > > drawback: we loose original jar and its signature > > > > > > > > > > On the other branches, the current poc shows commits for versions > > that > > > > are > > > > > perfectly linear: if there are multiple branches that are released > in > > > > > parallel, the commit won't be so clean. I don't know if this will > > have > > > an > > > > > impact on compression efficiency. > > > > > > > > > > Another issue with this idea: during development, with SNAPSHOTs, > the > > > git > > > > > repo > > > > > will be polluted: this idea IMHO could only be valid for releases > > > > > > > > > > not to speak about read concurrency when one requires to use > multiple > > > > > versions > > > > > of a lib. And of course, write concurrency is even harder. > > > > > > > > > > > > > > > Definitely, the idea is funny, but I don't see how this could go > very > > > far > > > > > than > > > > > this funny idea (in addition to the complexity for implementing > this > > > > > format in > > > > > tooling) > > > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit : > > > > > > One more repo: > > > > > > > > > > > > https://github.com/paul-hammant/mc-xs-all/ > > > > > > > > > > > > One branch for each of classes, javadoc, sources, and poms > > > > > > > > > > > > 15 javadoc original versions: 24.1M > > > > > > > > > > > > 16 sources original versions: 4.9M > > > > > > > > > > > > 27 classes original versions: 8.4M > > > > > > > > > > > > Afterwards git work the bare .git folder is: 8.4M > > > > > > > > > > > > *77.5% saving on storage* > > > > > > > > > > > > Any artifact, *including the poms,* can be pulled down via a > single > > > git > > > > > > command > > > > > > > > > > > > git clone https://github.com/paul-hammant/mc-xs-classes --depth > 1 > > > > > --branch > > > > > > TAGNAME > > > > > > > > > > >
Re: Silly Saturday idea - If Maven Central were a bunch of Git repos
Just a friendly reminder that git is not optimized for large files (for this, they made git-lfs). Plus, when you do checkout a git repo, there's no binary diffs - so if you've got plenty of releases, you'll be wasting a lot of space/time in terms of transmission and storage. -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Wed, May 17, 2017 at 9:37 AM, Paul Hammant <p...@hammant.org> wrote: > We can agree to differ on what I'm suggesting and what the impact of that > would be :) > > On Wed, May 17, 2017 at 8:59 AM, Brian Fox <bri...@infinity.nu> wrote: > > > Even more than redefining what Central does, you're effectively > describing > > a new, unofficial java class packaging and distribution mechanism. This > > seems like it will violate signatures etc and make tracking of what you > > actually have a nightmare. > > > > On Tue, May 16, 2017 at 5:55 PM, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > > > > this idea of putting everything in git is funny: not sure this will go > > very > > > far from this poc, but let's imagine... > > > > > > on classes branch, splitting the jar into individual .class has IMHO a > > big > > > drawback: we loose original jar and its signature > > > > > > On the other branches, the current poc shows commits for versions that > > are > > > perfectly linear: if there are multiple branches that are released in > > > parallel, the commit won't be so clean. I don't know if this will have > an > > > impact on compression efficiency. > > > > > > Another issue with this idea: during development, with SNAPSHOTs, the > git > > > repo > > > will be polluted: this idea IMHO could only be valid for releases > > > > > > not to speak about read concurrency when one requires to use multiple > > > versions > > > of a lib. And of course, write concurrency is even harder. > > > > > > > > > Definitely, the idea is funny, but I don't see how this could go very > far > > > than > > > this funny idea (in addition to the complexity for implementing this > > > format in > > > tooling) > > > > > > Regards, > > > > > > Hervé > > > > > > Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit : > > > > One more repo: > > > > > > > > https://github.com/paul-hammant/mc-xs-all/ > > > > > > > > One branch for each of classes, javadoc, sources, and poms > > > > > > > > 15 javadoc original versions: 24.1M > > > > > > > > 16 sources original versions: 4.9M > > > > > > > > 27 classes original versions: 8.4M > > > > > > > > Afterwards git work the bare .git folder is: 8.4M > > > > > > > > *77.5% saving on storage* > > > > > > > > Any artifact, *including the poms,* can be pulled down via a single > git > > > > command > > > > > > > > git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 > > > --branch > > > > TAGNAME > > > > > > > > 74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5, > > > > classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2, classes-1.1, > > > > classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2, > > classes-1.2.1, > > > > classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4, > classes-1.4.1, > > > > classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5, > > > classes-1.4.6, > > > > classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2, > > javadoc-1.2.1, > > > > javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4, > javadoc-1.4.1, > > > > javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5, > > > javadoc-1.4.6, > > > > javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1, > > > pom-1.2.2, > > > > pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3, > > pom-1.4.4, > > > > pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9, sources-1.1.3, > > > > sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3, > sources-1.3.1, > > > > sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3, > > sources-1.4.4, > > > > sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8, > > sources-1.4.9 > > > > > > > > - Paul > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
Re: Silly Saturday idea - If Maven Central were a bunch of Git repos
This is quite similar to what "go get" does to golang. I'd say its worth a try On May 14, 2017 09:28, "Paul Hammant"wrote: > Article updated to eliminate misunderstandings and talk about a different > index for 'maven central' too. > > - ph > > On Sat, May 13, 2017 at 3:04 PM, Paul Hammant wrote: > > > I was discussing this of the list today, and it may interest people on > dev@ > > > > https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/ > > > > "Maven Central as multiple Git repositories" > > > > Enjoy, > > > > - Paul > > >
Re: Publish Maven releases on SDKMAN!
just fyi: github releases has an atom feed. https://github.com/apache/maven/releases.atom -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Sun, Apr 16, 2017 at 4:49 AM, Marco Vermeulen <vermeulen...@gmail.com> wrote: > Hi Heinz, > > On Sun, 16 Apr 2017 at 08:41 Karl Heinz Marbaise <khmarba...@gmx.de> > wrote: > > > Hi, > > > > On 16/04/17 00:56, Marco Vermeulen wrote: > > > Hi Maven folks, > > > > > > Some time ago I asked the Maven dev community whether they would be > > willing > > > to publish their releases on SDKMAN! [1] using our Vendor API [2]. > > > Unfortunately, my request was met with scepticism and ultimately > resulted > > > in no action taken. > > > > What happended out of the idea to scan automatically[1] for new versions > > and insert the data automatically via a crawler which can for example > > scan maven central[2] where all releases of Maven will be distributed > > (also there is a REST API on Maven Central)...or the distirbution > pages... > > > > > The idea to scan/crawl is not feasible for me as crawlers are brittle and > time consuming to maintain. I provide SDKMAN in my spare time to help > others, so don't want to spend my time maintaining something like this. > Moreover, why write a piece of infrastructure when a simple API call from > your side would do the trick? It would take almost no effort. > > > > > > [1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html > > [2]: > > > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org. > apache.maven%22%20AND%20a%3A%22apache-maven%22 > > > > > > > > > > I would like to appeal to the Maven dev community again to take on the > > > responsibility of managing their own releases on our platform. > > > > Hm...maybe I misunderstand here a thing but which responsibily does the > > Maven dev community has on your platform ? > > > > From my personell point view: none > > > > The maven community has no responsibility, I am asking your community for > help. I'm asking you in a friendly manner to take on the responsibility of > publishing, you misunderstood my intent. > > > > > > > The process > > > is very simple: It involves making a few REST calls to our API and > > > instantaneously releases become available for all the SDKMAN! users out > > > there. > > > > This is the point which is the problem...or the "scepticism" you > > mentioned... > > > > To be honest you seemed to be ignoring the suggestions for improvements > > on your platform which could make it easier to integrate parts on your > > platform...not only for us also for many other tools...which would > > improve the accepting for the support of your platform... > > > > All the others communities out there were more than happy to do the API > call. This community being the first out of all the others to show any > resistance. Empowering SDK vendors by exposing an API seems by far more > preferred among our vendors as it puts them in control of their own > releases. Releases become available fast and reliably, and they have full > control over this. > > > > > > In earlier days you have declined[1] to support maven at all now you > > have changed your mind which of course is fine... > > > > Yes, I changed my mind because I was urged [1] to do so on twitter by your > very own twitter account. > > [1] https://twitter.com/ASFMavenProject/status/851132246669103108 > > > > > [3]: https://issues.apache.org/jira/browse/MNG-5749 > > > > > > > > Many other teams are already doing this, including Gradle, Kotlin, > > Groovy, > > > Ceylon and Spring Boot to name a few. It would be great to have you > guys > > on > > > board too. > > > > > > I currently perform these releases for Maven manually, which > > unfortunately > > > is not something I can sustain going forward. > > > > If the sdkman user community has already asked for support why don't you > > solve the problem ? > > > > > The problem has long been solved by us exposing an API. The problem here > seems to be with an insular community who does not want to reach out to > others to help. In this case, by making a simple API call at release time. > > > > In three ways. Removing the manuall work for yourself, the acceptance of > > your platform to support more tools and finally fulfill the need of your > > user community...(Which I think is the most important pa
Re: Publish Maven releases on SDKMAN!
Ironically, I've ported nvm (for node), but for Maven <https://github.com/ingenieux/mvm>, but ended up using sdkman later. I wonder if it would be interesting to have a service to generate webhooks and rss feeds for new versions/releases on github and apache overall. -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Sun, Apr 16, 2017 at 2:41 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi, > > On 16/04/17 00:56, Marco Vermeulen wrote: > >> Hi Maven folks, >> >> Some time ago I asked the Maven dev community whether they would be >> willing >> to publish their releases on SDKMAN! [1] using our Vendor API [2]. >> Unfortunately, my request was met with scepticism and ultimately resulted >> in no action taken. >> > > What happended out of the idea to scan automatically[1] for new versions > and insert the data automatically via a crawler which can for example scan > maven central[2] where all releases of Maven will be distributed (also > there is a REST API on Maven Central)...or the distirbution pages... > > > [1]: https://www.mail-archive.com/dev@maven.apache.org/msg108018.html > [2]: http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apach > e.maven%22%20AND%20a%3A%22apache-maven%22 > > > >> I would like to appeal to the Maven dev community again to take on the >> responsibility of managing their own releases on our platform. >> > > Hm...maybe I misunderstand here a thing but which responsibily does the > Maven dev community has on your platform ? > > From my personell point view: none > > > The process > >> is very simple: It involves making a few REST calls to our API and >> instantaneously releases become available for all the SDKMAN! users out >> there. >> > > This is the point which is the problem...or the "scepticism" you > mentioned... > > To be honest you seemed to be ignoring the suggestions for improvements on > your platform which could make it easier to integrate parts on your > platform...not only for us also for many other tools...which would improve > the accepting for the support of your platform... > > In earlier days you have declined[1] to support maven at all now you have > changed your mind which of course is fine... > > [3]: https://issues.apache.org/jira/browse/MNG-5749 > > >> Many other teams are already doing this, including Gradle, Kotlin, Groovy, >> Ceylon and Spring Boot to name a few. It would be great to have you guys >> on >> board too. >> >> I currently perform these releases for Maven manually, which unfortunately >> is not something I can sustain going forward. >> > > If the sdkman user community has already asked for support why don't you > solve the problem ? > > In three ways. Removing the manuall work for yourself, the acceptance of > your platform to support more tools and finally fulfill the need of your > user community...(Which I think is the most important part here). > > In particular if it could be done by using a curl call on maven central or > a little bit more if you like to scan the http://maven.apache.org/docs/h > istory.html page (jsoup is very easy) from your site... > > In a nutshell I would say why not implementing a scan service yourself > which takes some time, but I got the impression that writing all these > mails/tickets etc. and discussions takes more time than implementing such a > service... > > > Kind regards > Karl Heinz Marbaise > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Thoughts on MR-Jar support in Maven
Wouldn't preprocessing help? https://blog.jooq.org/2016/03/01/how-to-support-java-6-8-9-in-a-single-api/ -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Fri, Mar 24, 2017 at 11:01 AM, Andreas Sewe < s...@st.informatik.tu-darmstadt.de> wrote: > Hi, > > > I would have thought that it was not Maven's responsibility to ascertain > > that test passed in various JDKs, old and new. > > I agree that is is not Maven's responsibility to (out of the box) > execute the tests against multiple JREs. If you think it is, one can > just as well argue that it should run tests for OSGi bundles built with > Maven using all different permutations that the bundle's Import-Package > version ranges allow. > > Yes, there are projects where that level of double-checking is > warranted, but IMHO this is the domain of Jenkins matrix projects or > similar mechanisms. > > The bigger issue with the "multiple source folder per project" approach > is whether popular IDEs can express the fact that src/main/java needs to > be compiled against one JRE whereas src/main/java-9 needs to be compiled > against another. > > Just my two cents. > > Andreas > >
Re: Requesting a single Monorepo enhancement for Maven
Actually, I always wondered if it was interesting to have a tool to allow the modification of POM files from Command Line. Like setting a property, adding a dependency and/or, as you exposed, changing modules. -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Tue, Jan 24, 2017 at 12:05 AM, Paul Hammant <hamm...@apache.org> wrote: > OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and > it's usage of shell scripts to subset the checkout for speedy development: > >http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/ >https://trunkbaseddevelopment.com/monorepos/ > > For Maven to be used with a scripted use of Subversion or Git's > sparse-checkout (or Perforce's client spec), it'd been to be more like > Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they > are discovered/calculated/inferred somehow. > > In pom.xml instead of - > > > one > two > > > We'd need - > > > recursively > > > Or - > > > .full-module-list.txt > > > > Thoughts? > > Any questions? > > - Paul H > > PS - I'm a solid Maven user since 2003. >
Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process
There are cases where one could use a profile to build a custom assembly of the war (say, like with jetty runner to run under a given paas), and attaching just the relevant classes / assets, thus saving time. -- -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte <rfscho...@apache.org> wrote: > Hi, > > I really wonder why it is useful to add a skip-parameter to the packaging > plugin? The goal for every Maven project is to end up with some (packaged) > artifact, right? > A skip-parameter because a lot of other plugins have it as well is IMHO > not a good reason, so what would be a valid usecase here? > > thanks, > Robert > > Op Mon, 25 Jan 2016 20:28:39 +0100 schreef Karl Heinz Marbaise (JIRA) < > j...@apache.org>: > > >> [ >> https://issues.apache.org/jira/browse/MWAR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Karl Heinz Marbaise closed MWAR-350. >> >> Resolution: Fixed >> Assignee: Karl Heinz Marbaise >> >> Fixed in [r1726671|http://svn.apache.org/r1726671] >> >> Add Skip Parameter to Skip the process >>> -- >>> >>> Key: MWAR-350 >>> URL: https://issues.apache.org/jira/browse/MWAR-350 >>> Project: Maven WAR Plugin >>> Issue Type: New Feature >>>Affects Versions: 2.6 >>> Environment: Maven 3.3.3 >>> maven-war-plugin 2.6 >>>Reporter: Keshan De Silva >>>Assignee: Karl Heinz Marbaise >>>Priority: Trivial >>> Fix For: 3.0.0 >>> >>> Attachments: Maven_War_Skip.patch >>> >>> >>> * It will be usefull if maven-war plugin has a skip configuration as in >>> most of the plugins have. >>> {code:xml} >>> org.apache.maven.plugins >>> maven-war-plugin >>> 2.6 >>> >>> true >>> >>> {code} >>> (I have attached a patch file) >>> >>> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.4#6332) >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Jekyll experiment
JBake supports both markdown and adoc btw :) -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Thu, Mar 19, 2015 at 1:27 PM, Manfred Moser manf...@mosabuam.com wrote: I agree with the suggestion to use asciidoctor as a format. Markdown seems to limited and require escaping to straight html or other hacks way too often. And on the need to clean up the site I would be willing to help as well. We need a fresh clean site. Maybe even with the Owl ;-) manfred Jeff Jensen wrote on 19.03.2015 04:51: +1 asciidoctor On Thu, Mar 19, 2015 at 4:56 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: While I use jekyll for lots of stuff (blogs and wicket website), I'd urge to use asciidoc[tor] as the markup format. Markdown is great, but rather limited for technical documentation. There is some asciidoctor integration for jekyll available [1], but I haven't used it in anger. Just my 2 cts. Martijn [1] https://google.com/search?q=jekyll%20asciidoctor On Thu, Mar 19, 2015 at 4:32 AM, Jason van Zyl ja...@takari.io wrote: Anyone interested in trying a Jekyll experiment for our website? Extract the useful documentation we believe there is and try to make working on the site a pleasurable experience that is easy for users to contribute to? I'd like to try this because after this last release I'm frankly tired of looking at our pretty awful website. It's ugly, noisy, unmaintained, hard to navigate and personally just makes me not want to write anything. I would like to like writing documentation again and I think a more standard tool like Jekyll will help. I honestly dislike doing core releases because I have to use the site plugin. I created it, I can hate it and I do hate it. Even if no one answers I'll try this experiment because I think there's only 10-15 useful documents in the whole site so it likely won't take long. Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - 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: Jekyll experiment
you seen JBake? I wrote its Maven Plugin http://docs.ingenieux.com.br/project/jbake/ -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Thu, Mar 19, 2015 at 12:32 AM, Jason van Zyl ja...@takari.io wrote: Anyone interested in trying a Jekyll experiment for our website? Extract the useful documentation we believe there is and try to make working on the site a pleasurable experience that is easy for users to contribute to? I'd like to try this because after this last release I'm frankly tired of looking at our pretty awful website. It's ugly, noisy, unmaintained, hard to navigate and personally just makes me not want to write anything. I would like to like writing documentation again and I think a more standard tool like Jekyll will help. I honestly dislike doing core releases because I have to use the site plugin. I created it, I can hate it and I do hate it. Even if no one answers I'll try this experiment because I think there's only 10-15 useful documents in the whole site so it likely won't take long. Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Plugin and Maven Metrics
Just wondering if you guys are using anything particular to collect runtime metrics and usage, specially for Plugin Statistics (not download statistics - I've got a particular case where I can't say what are some key metrics for some of my stuff) I know there's metrics, but I wonder if there's something Open for Hosting usage for Plugin Developers. If not, could we consider it? (Of course, obeying all privacy statements and stuff) Thanks -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/
Re: Plugin and Maven Metrics
Seems like Metrics - which is good. But I wonder if any of you guys ever had this need from a plugin development standpoint, and how you addressed it -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Fri, Nov 21, 2014 at 1:46 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi Can't it use Sirona? - not sure i fully got what you want to do but since it is Apache as well... Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-11-21 17:43 GMT+01:00 Aldrin Leal ald...@leal.eng.br: Just wondering if you guys are using anything particular to collect runtime metrics and usage, specially for Plugin Statistics (not download statistics - I've got a particular case where I can't say what are some key metrics for some of my stuff) I know there's metrics, but I wonder if there's something Open for Hosting usage for Plugin Developers. If not, could we consider it? (Of course, obeying all privacy statements and stuff) Thanks -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: exclude on scope import
(TL;DR: Use this repo and the versions on your dependencyMgmt: http://version99.qos.ch/) a hack, but works like a charm: http://day-to-day-stuff.blogspot.com.br/2007/10/announcement-version-99-does-not-exist.html -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jan 20, 2014 at 6:12 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The hack way I would use is to create an intermediate wrapper project and then you can define exclusions on that wrapper at the pom level directly. Other than that you just have to wait for model version 5.0.0 when the provides element that I want to introduce would allow either slf4j's binder to advertise that it provides commons-logging, or you would be able to state that in your dependency directly On 20 January 2014 09:03, Stephane Nicoll stephane.nic...@gmail.com wrote: Hi, Has anybody thought (or worked on) the ability to exclude dependencies from the import of a pom for a given project. Let's say that project S uses commons-logging and we use that project in our project. We have something like dependency groupId/groupId artifactIdthe-s-project/artifactId version.../version typepom/type scopeimportscope /dependency Now I'd like to exclude the commons-logging dependency from the whole project so that I can use the slf4j binder instead. Thoughts? Thanks, S.
Re: SPDX Maven Plugin
I believe m2eclipse does have some built-in completion for that, and yes, I'm interested -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jan 20, 2014 at 2:20 PM, Gary O'Neall g...@sourceauditor.comwrote: Greetings all, I am somewhat new to Maven plugin development and would like to ask the developer community for some feedback and help in developing a plugin to generate project license metadata compliant with the Software Product Data Exchange (SPDX) standard. The SPDX specification is a standard format for communicating the components, licenses and copyrights associated with a software package. We are on version 1.2 of the spec and is in use at several of the SPDX participating companies (see www.spdx.org for more info). The motivation for the plugin was the result of a discussion between Phil Odence and myself (from SPDX) and Jim Jagielski and Henri Yandell (from Apache) on ideas for how Apache projects could produce or utilize SPDX. It was suggested that a maven plugin would substantially reduce the effort for several Apache projects. Over the past couple weeks, I have studied the Maven Mojo and plugin API's and produced a prototype which will generate an SPDX file based on a POM file. You can find the code on Github at https://github.com/goneall/spdx-maven-plugin Here's my questions for the Maven Developers: - Is anyone on the list interested and have some time to collaborate on the plugin? I'm pretty comfortable on the Java and SPDX output coding, but I'm new to Maven and could use some experienced review of some of my choices regarding Maven parameters and implementation. A review of the code would be most appreciated. I could also post the more specific questions to this list if that is appropriate. - Are there any related efforts I should be aware of? (Note: I did find another spdx maven plugin on github. I reached out to the author and have not heard back, so I'm not sure how active the project is). - Once the plugin is built and unit tested, what is the best way to make it more accessible to other developers? - A spreadsheet mapping the SPDX properties to either spdx-maven-prototype configuration parameters or existing Maven model properties can be downloaded at https://github.com/goneall/spdx-maven-plugin/blob/master/SPDX-fields-maven-m apping.xlsx. Feedback on the prototype choices are welcome. There is also a proposed longer term mapping, some of which extends the current Maven model. Thanks in advance, Gary - Gary O'Neall Principal Consultant Source Auditor Inc. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Converting site documentation to Markdown
There's a great comprehensive list at http://staticsitegenerators.net (btw, I've wrote the jbake-maven-plugin, for jbake - https://github.com/jonbullock/JBake) -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Sun, Oct 6, 2013 at 12:20 PM, Jason van Zyl ja...@tesla.io wrote: Here's a pretty good list of tools. The other two I've tried are Marked (which is another MAC app), but I've also tried dillinger.io which is web-based editor and it's quite good. There are quite a few web-based tools that provide similar capabilities to Mou. http://mashable.com/2013/06/24/markdown-tools/ On Oct 5, 2013, at 11:19 AM, Jason van Zyl ja...@tesla.io wrote: We current have multiple formats for our site documentation and two of them no one else in the world uses except us. We created xdoc here a long time ago in the Jakarta project, and APT has lost in the world of markup. I ported it from another project many years ago but there are many better options like asciidoc, restructured text, and markdown. My preference is for markdown but I would like to get rid of xdoc, fml, and xdoc and convert that documentation over to markdown. The tool support is great for editing, book support is great (the Pro Git book is created from markdown). We can still use all the Doxia tools for all the post processing. But I see no need to 4 different types of markup for the site, and honestly I find working with APT now incredibly annoying. I'm happy to do the conversion and testing. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: github plugin?
Wouldn't scm:bootstrap work? -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jun 3, 2013 at 6:32 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi guys, is there any maven github plugin (or any plan)? the goal would be to get what we have with gem for instance in ruby world to be able to clone a repo from the build to consider it as a dependency. For java (and script jsr in particular) it would be great to get an additional step: resource copy selection. Basically here what it would be an interesting workflow: 1) git clone a branch on a repo in ${repo} 2) copy folder F or ${repo} in target/classes (copying the whole repo will make the scripting JSR - aka JSR223 - not found the scripts in general) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau*
Re: github plugin?
I wonder if commons-vfs does offer some scm functionality. If it doesn't, it would be just as amazing... -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jun 3, 2013 at 10:00 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: scm plugin is what i was looking for, exec plugin was not portable enough *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/6/3 Chris Graham chrisgw...@gmail.com Use the exec plugin? -Chris Sent from my iPhone On 03/06/2013, at 7:32 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi guys, is there any maven github plugin (or any plan)? the goal would be to get what we have with gem for instance in ruby world to be able to clone a repo from the build to consider it as a dependency. For java (and script jsr in particular) it would be great to get an additional step: resource copy selection. Basically here what it would be an interesting workflow: 1) git clone a branch on a repo in ${repo} 2) copy folder F or ${repo} in target/classes (copying the whole repo will make the scripting JSR - aka JSR223 - not found the scripts in general) wdyt? *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Committer School] I would like to become a committer
Amazing to hear IBM has adopted Maven -- -- Aldrin Leal, ald...@leal.eng.br / http://meadiciona.com/aldrinleal On Thu, Jul 12, 2012 at 10:16 AM, Chris Graham chrisgw...@gmail.com wrote: He He. I'd emailed myself the link from Stephen's twitter blog link at the same time he's posted this to the list. :-) I am interested in the following areas: *SCM, Release Plugin* I've already contributed the scm-provider-jazz module for the 1.7 release. And, working for IBM, I could probably also cover ClearCase (or at least be able to test it). I belive that the required ICA is already on file. Maven, and particularly the release plugin, has saved IBM and it's client's literally millions of dollars, so I'm happy to give something back. -Chris
Re: Maven plugin in ant/beanshell
ant yes Sonatype's Book actually covers ithttp://www.sonatype.com/books/mcookbook/reference/ch04s04.html -- -- Aldrin Leal, ald...@leal.eng.br / http://meadiciona.com/aldrinleal On Sat, May 12, 2012 at 6:36 PM, Olivier Lamy ol...@apache.org wrote: Hi, Do we still maintain those extractor ? Do you think users write maven plugin in ant/beanshell ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 1.5 Annotations for Mojo
Err, I did upload to central (the 1.4.1 release). http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22br.com.ingenieux.maven.annomojo%22 I wish those could be resolved. JFrog's solution is great and it works like a charm. -- -- Aldrin Leal, ald...@leal.eng.br / http://meadiciona.com/aldrinleal On Fri, Apr 27, 2012 at 2:34 PM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Hi there, I think JFrog (the Artifactory guys) has already published a set of Java 1.5 annotations for mojo development, including a m-plugin-p extension to use them. The source code is available on github [1], but unfortunately the artifacts are not available in Central (there is a ticket in JFrog's JIRA [2] regarding this problem). They even have reasonably complete documentation [3] plus it's all under ASL 2.0 AFAICS. From my own experience, these annotations work quite well. Shouldn't they be incorporated or used as a starting point? I guess starting from JFrog's annotations will not only save a considerable amount of development time, but also increase acceptance with those plugin developers which already used the existing JFrog annotations in the past. Best regards Ansgar [1] https://github.com/JFrogDev/maven-anno-mojo [2] https://issues.jfrog.org/jira/browse/ANMJ-18 [3] http://wiki.jfrog.org/confluence/display/OSS/Maven+Anno+Mojo Am 27.04.2012 16:37 schrieb Olivier Lamy ol...@apache.org: Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: substitute a repository with another one in pom.xml?
You can create a mirror. If you supply the right id, it will simply work. http://maven.apache.org/guides/mini/guide-mirror-settings.html -- -- Aldrin Leal, ald...@leal.eng.br / http://meadiciona.com/aldrinleal On Tue, Mar 27, 2012 at 11:17 AM, ryenus blatt rye...@gmail.com wrote: hello, in pom.xml, is it possible to setup a substitution rule to replace a repository with another one? e.g.: repository idxxx/id urlhttp://yyy.org//url subsitutehttp://zzz.org//substitute /repository the reason is, in case the repository zzz.org is down, with the substitution rule set, maven can immediately turn to yyy.org, instead of try zzz.org and wait and fail then turn to yyy.org, the latter, which is the current situation, would waste a lot of time if their are too many (e.g. 100+) artifacts supposed to be fetched from zzz.org. my case? maven.glassfish.org is down and it took me more than 30 mins to run mvn eclipse:eclipse, the project is https://github.com/ikeike443/HudsonPluginForPlay
Best Practices for Proxy and Mojos
Folks, Just a question: How do you deal with HTTP Proxies into your mojos. Is there an standard or sample source to point me to? Thank you -- -- Aldrin Leal, ald...@leal.eng.br / http://meadiciona.com/aldrinleal
Re: Julia Antonova/Tumlare is out of office.
Should I file a bug? The email says she's in vacation but the docs tell me the other way. What to do? I am unable to tell whether or not Julia Antonova Tumlare is in the office/vacation/whatever/ -- -- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/ On Tue, Feb 22, 2011 at 5:22 PM, Anders Hammar and...@hammar.net wrote: Right, it's a weird thing called vacation that most humans have...unlike computers and bots... /Anders On Tue, Feb 22, 2011 at 21:10, Martin Gainty mgai...@hotmail.com wrote: so if i understand..her employer is PAYING her NOT to come into the office and NOT to answer any email ? Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Tue, 22 Feb 2011 14:05:21 -0600 Subject: Re: Julia Antonova/Tumlare is out of office. From: jesse.mcconn...@gmail.com To: dev@maven.apache.org CC: and...@hammar.net this always brings a smile to my face...its been so many years now. cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Feb 22, 2011 at 13:40, Anders Hammar and...@hammar.net wrote: http://docs.codehaus.org/pages/viewpage.action?pageId=160694277 Just a reminder for the rest of us that we have far too few vacation days. /Anders On Tue, Feb 22, 2011 at 20:35, Dan Tran dant...@gmail.com wrote: I keep seeing 'Wiki updated.' . What is it about? -D On Tue, Feb 22, 2011 at 11:30 AM, Stephane Nicoll stephane.nic...@gmail.com wrote: ah ah :) 2011/2/22 Tamás Cservenák ta...@cservenak.net: Wiki updated. On Tue, Feb 22, 2011 at 8:07 PM, Julia Antonova juli...@tumlare.com wrote: I will be out of the office starting 22.02.2011 and will not return until 24.02.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you! - 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