Re: How secure is invoking a single mojo?

2022-12-28 Thread Aldrin Leal
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?

2022-12-16 Thread Aldrin Leal
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?

2022-12-16 Thread 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?

Thank you
--
-- Aldrin Leal,  / https://aldrinleal.link


Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

2017-05-17 Thread Aldrin Leal
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

2017-05-17 Thread Aldrin Leal
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

2017-05-17 Thread Aldrin Leal
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

2017-05-17 Thread Aldrin Leal
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

2017-05-14 Thread Aldrin Leal
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!

2017-04-16 Thread Aldrin Leal
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!

2017-04-16 Thread Aldrin Leal
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

2017-03-24 Thread Aldrin Leal
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

2017-01-23 Thread Aldrin Leal
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

2016-01-25 Thread Aldrin Leal
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

2015-03-19 Thread Aldrin Leal
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

2015-03-18 Thread Aldrin Leal
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

2014-11-21 Thread Aldrin Leal
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

2014-11-21 Thread Aldrin Leal
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

2014-01-20 Thread Aldrin Leal
(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

2014-01-20 Thread Aldrin Leal
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

2013-10-06 Thread Aldrin Leal
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?

2013-06-03 Thread Aldrin Leal
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?

2013-06-03 Thread Aldrin Leal
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

2012-07-14 Thread Aldrin Leal
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

2012-05-12 Thread Aldrin Leal
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

2012-04-27 Thread Aldrin Leal
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?

2012-03-27 Thread Aldrin Leal
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

2011-09-23 Thread Aldrin Leal
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.

2011-02-22 Thread Aldrin Leal
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