Re: Publish Via the Central Portal

[Brian Fox]

We worked with Andres to get the apis supported in Jreleaser. If someone is
interested in working with us to do the same natively in the deploy plugin,
I would champion that and make sure we get the API information to them. I
just don't have the time or developer capacity to do it directly right now.

On Wed, May 1, 2024 at 10:33 PM Romain Manni-Bucau 
wrote:

> Hi,
>
> Nexus plugin works well with maven 4 but has a limitation with java version
> ootb if you dont force plugin dependency version.
> From my side the main issue is it got abandonned - fix was there but no
> release (at least after months and before I moved back to deploy or a tuned
> gitflow plugins).
>
> Guess we should be able to support it in deploy plugin if protocol requires
> changes to ensure some continuity and maintenance in time?
>
> Le jeu. 2 mai 2024 à 01:29, Slawomir Jaranowski  a
> écrit :
>
> > Thanks Brian for responding.
> >
> > From the time when nexus-staging-plugin was introduced we have done many
> > improvements in standard deploy plugin - like deploy at the end,
> uploading
> > artifacts in parallel.
> >
> > We are also working on Maven 4, so today the plugin should be possible to
> > use with the next Maven major version.
> > As I remember nexus-staging-plugin can not be used with Maven 4.
> > Can a new plugin be used with Maven 4?
> >
> >
> > śr., 1 maj 2024 o 17:50 Brian Fox  napisał(a):
> >
> > > Hey all. Thanks Romain for pointing out the thread for me.
> > >
> > > One issue is that Central publishers is a much larger set of folks than
> > the
> > > Maven Dev group. Obviously there's lots of overlap, but as Romain said,
> > > creating a plugin is a thing that can be done independently.
> > >
> > > As we've been working towards refreshing the infra used to publish to
> > > Central, we have reached out collaboratively to other known tools that
> > > required support. Specifically Gradle and also Andres / JReleaser to
> > ensure
> > > that there is broad tooling support for the new apis. Since we created
> a
> > > Maven plugin ourselves, and it is largely based on the long standing
> > Nexus
> > > staging plugin, it wasn't apparent that any conversation was needed
> here.
> > >
> > > We will need to dig in other Maven Compat and opening the source
> however
> > so
> > > good call outs.
> > >
> > > On Tue, Apr 30, 2024 at 6:11 AM Andres Almiray 
> > wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > In the meantime JReleaser offers support for both publishing to the
> > > Portal
> > > > and handling build poms
> > > >
> > > > https://github.com/jreleaser/jreleaser/issues/1612
> > > > https://github.com/jreleaser/jreleaser/issues/1632
> > > >
> > > > FWIW the Portal API is publicly available at
> > > > https://central.sonatype.org/publish/publish-portal-api/
> > > > Sonatype's plugin may not offer source code but JReleaser does.
> > However,
> > > > it's implementation relies on Feign. You may study and adapt the code
> > if
> > > > you feel like it, after all it's licensed under ASL v2
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/jreleaser/jreleaser/tree/main/sdks/jreleaser-mavencentral-java-sdk
> > > >
> > > > Cheers,
> > > > Andres
> > > >
> > > > ---
> > > > Java Champion; Groovy Enthusiast
> > > > https://andresalmiray.com
> > > > https://www.linkedin.com/in/aalmiray
> > > > --
> > > > What goes up, must come down. Ask any system administrator.
> > > > There are 10 types of people in the world: Those who understand
> binary,
> > > and
> > > > those who don't.
> > > > To understand recursion, we must first understand recursion.
> > > >
> > > >
> > > > On Tue, Apr 30, 2024 at 12:05 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > AFAIK and if I got right the info from Brian, this is not yet
> > promoted
> > > > and
> > > > > the primary solution but will become soon.
> > > > >
> > > > > Personally I'm not that shocked we were not consulted - w

Re: Publish Via the Central Portal

[Brian Fox]

Hey all. Thanks Romain for pointing out the thread for me.

One issue is that Central publishers is a much larger set of folks than the
Maven Dev group. Obviously there's lots of overlap, but as Romain said,
creating a plugin is a thing that can be done independently.

As we've been working towards refreshing the infra used to publish to
Central, we have reached out collaboratively to other known tools that
required support. Specifically Gradle and also Andres / JReleaser to ensure
that there is broad tooling support for the new apis. Since we created a
Maven plugin ourselves, and it is largely based on the long standing Nexus
staging plugin, it wasn't apparent that any conversation was needed here.

We will need to dig in other Maven Compat and opening the source however so
good call outs.

On Tue, Apr 30, 2024 at 6:11 AM Andres Almiray  wrote:

> Hello everyone,
>
> In the meantime JReleaser offers support for both publishing to the Portal
> and handling build poms
>
> https://github.com/jreleaser/jreleaser/issues/1612
> https://github.com/jreleaser/jreleaser/issues/1632
>
> FWIW the Portal API is publicly available at
> https://central.sonatype.org/publish/publish-portal-api/
> Sonatype's plugin may not offer source code but JReleaser does. However,
> it's implementation relies on Feign. You may study and adapt the code if
> you feel like it, after all it's licensed under ASL v2
>
>
> https://github.com/jreleaser/jreleaser/tree/main/sdks/jreleaser-mavencentral-java-sdk
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> https://andresalmiray.com
> https://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Tue, Apr 30, 2024 at 12:05 PM Romain Manni-Bucau  >
> wrote:
>
> > Hi,
> >
> > AFAIK and if I got right the info from Brian, this is not yet promoted
> and
> > the primary solution but will become soon.
> >
> > Personally I'm not that shocked we were not consulted - we build plugin
> API
> > for that exact purpose, let people do what they need to do.
> >
> > About maven-compat it i mainly about us making it obvious it will fail
> but
> > I think it will be fixed for the final GA release.
> >
> > So from my small window there is no concern even if most of us using
> > central outside the asf will be impacted sometime next year probably.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 30 avr. 2024 à 10:32, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > a écrit :
> >
> > > Hi,
> > >
> > > Does anyone try the new Sonatype Central Portal?
> > > https://central.sonatype.org/publish-ea/publish-ea-guide/
> > >
> > > There is a new (*) Maven plugin provided by Sonatype for deployments:
> > > https://central.sonatype.org/publish/publish-portal-maven/
> > >
> > > But I am afraid that this plugin will be similar
> > > to nexus-staging-maven-plugin and still use maven-compat ...
> > > Probably it will have a problem with Maven 4 ...
> > > Also Sonatype did not publish a source code for it ...
> > >
> > >
> >
> https://central.sonatype.com/artifact/org.sonatype.central/central-publishing-maven-plugin
> > >
> > > Also Sonatype did not publish a source code for it ...
> > >
> > > It also looks as standard Maven deployment will not work with the new
> > > Central Portal API.
> > >
> > > I'm surprised that Sonatype did not consult or even announce such a new
> > way
> > > with the Maven community.
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

Re: [DISCUSS] Java version for Maven

[Brian Fox]

That feels right to me based on the data and all the discussion so far.

On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák  wrote:

> I think this starts to make reasonable picture:
>
> If you are on Java 8, use Maven 3
> If you are on Java 9+ use Maven 4 (once out).
>
> For start, Maven3 has no idea (notion) about "classpaths" vs "modulepaths"
> (is not quite true stated like this, it has SOME heuristics, that is mostly
> shoot-and-miss).
>
> So, I think it makes sense to have Maven 4 as Java 17, as folks in "big
> tech" with strict processes, policies and what not will not migrate anyway
> to Maven4. They have Maven3.
>
> T
>
>
> On Thu, Feb 22, 2024 at 9:23 PM Benjamin Marwell 
> wrote:
>
> > Brian, any Chance you could make a stacked 100% graph for every *week*
> > of the past two years?
> > We could then see where we are heading…
> > (or the raw numbers per week, so we could work with that).
> >
> > That's probably a lot to ask, but I think it will show us how "fast"
> > the progression was (and will be).
> >
> > @Tamas please consider the support times are different by vendor.
> > I have seen Java 8 support well beyond 2030 *shudder*.
> >
> > Seeing all those numbers, I now feel a lot more confident that Maven 4
> > should be 17 (runtime), 21 (build)
> > and Java 8 users should stay with 3.x.x.
> > Elliotte gave a good reason for this: There are two camps now (read:
> > ALREADY).
> > There is no reason to not go with either of them.
> >
> > Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox  >:
> > >
> > > We dumped 30 days because that gives a good snapshot of what's
> happening
> > > right now. If we dumped for example the whole year, then it really
> blurs
> > > the lines all over the place and things newer will be less prominent
> just
> > > because they didn't have as much time. 30 days is how we typically
> bucket
> > > things when we want a form of relative popularity.
> > >
> > > As far as toy projects skewing, Tamas is right, the scale of central
> data
> > > is so large that it's insignificant. Also remember we only counted each
> > IP
> > > once per entry so even projects downloading over and over won't skew
> the
> > > results.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Java version for Maven

[Brian Fox]

We dumped 30 days because that gives a good snapshot of what's happening
right now. If we dumped for example the whole year, then it really blurs
the lines all over the place and things newer will be less prominent just
because they didn't have as much time. 30 days is how we typically bucket
things when we want a form of relative popularity.

As far as toy projects skewing, Tamas is right, the scale of central data
is so large that it's insignificant. Also remember we only counted each IP
once per entry so even projects downloading over and over won't skew the
results.

On Thu, Feb 22, 2024 at 10:24 AM Xeno Amess  wrote:

> > The raw numbers are a more reasonable picture.
> Elliotte, this is just the begin of maven 4, and maven 4.x is not just for
> current projects, but for projects in the next several years.(and I guess
> nobody here wanna increasing jdk major version during a same maven major
> version?)
> So if we agree that projects in future be more likely for higher jdk
> versions, I think the normalization somehow reasonable...Just IMO
>
> Elliotte Rusty Harold  于2024年2月22日周四 21:23写道：
>
> > This is all very interesting data for reasons that go well beyond Maven.
> > Thanks!
> >
> > My personal takeaway is that JDK 8 is a much bigger part of the market
> > than I would have guessed and Java 11 and Java 7 are both much less.
> > It looks to me like the Java world is dividing into two camps: The
> > "risk averse, stay with what works and what we know" camp on Java 8
> > and the Bleeding Edge camp on the latest LTS release.
> >
> > It's possible that's not what's really happening. Java 9 really broke
> > compatibility and caused a lot of pain for folks, so it might just be
> > a split between devs who were burned by Java 9+ and devs who weren't.
> >
> > Either way, we started with only the last 30 days of data so I don't
> > think the normalization is reasonable. The lifespan of Java 8, 11, and
> > 17 are all years before this data was taken so it's not like those
> > clients couldn't have moved to Java 17 for some part of the period.
> > The raw numbers are a more reasonable picture. I do not agree that the
> > weighted pie shows what's dead and what's sliding out.
> >
> > On Thu, Feb 22, 2024 at 4:17 AM Tamás Cservenák 
> > wrote:
> > >
> > > For start I "normalized" the Java strings to a form like "Java 8" or
> > "Java
> > > 17". This resulted in pretty much similar results as Romain PDF (Azul
> > > report).
> > >
> > > But then realized, we should consider this: Not every LTS existed at
> the
> > > same time span (and we discuss the future here, not the past). Here is
> > some
> > > history I collected:
> > >
> > > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java
> 1.8.0-401"
> > > (2024), that is 10 year span.
> > > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> > > (2024), that is a 6 year span.
> > > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> > > (2024), that is a 3 year span.
> > > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
> > (2024),
> > > that is 1 year span.
> > >
> > > So, "normalized" and "weighted" (by lifespan) results are these:
> > > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
> > >
> > > Weighted pie immediately shows which Java versions are "dead" (are
> > present,
> > > but are "sliding out") and which ones are "alive and kicking" (and
> > adoption
> > > is quite high).
> > >
> > > ---
> > >
> > > Refs:
> > > - https://www.java.com/releases/
> > > - https://openjdk.org/projects/jdk/11/
> > > - https://openjdk.org/projects/jdk/17/
> > > - https://openjdk.org/projects/jdk/21/
> > >
> > > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Maven UA is created like this:
> > > >
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> > > >
> > > > I was hoping also for a list of "Apache Maven ..." lines with
> &g

Re: [DISCUSS] Java version for Maven

[Brian Fox]

Hi everyone. I haven't caught up on this thread but Tamas pinged me to get
some usage data from Central. Attached are the Maven versions and JDK
Version counts as reported by User Agent by distinct IP for the last 30
days:





On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
 wrote:

>  I also want to stress that we care about what maven supports far more
> than what it requires to build.  If it needs JDK 17 to build but the jars
> are compliant with Java 8, that's fine with me.
>
> Hunter
>
> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain Manni-Bucau
>  wrote:
>
>  Hmm, not sure im ready for a 200M vanilla build tool even if it would have
> been ok legally...
>
> Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
>  a écrit :
>
> >  I might be wrong but I understood that shipping the JRE/JVM required a
> > license and this is why most people don't ship with a JVM bundled.  But
> > perhaps that has changed since the Oracle v Google/Alphabet trial.
> > Hunter
> >
> >On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin Marwell <
> > bmarw...@apache.org> wrote:
> >
> >  FWIW, bazel changed its runtime requirement to Java 21.
> > But they are shipping their own Java Runtime, so their users won't
> notice.
> > [1]
> >
> > I think they are the first build tool to do that.
> >
> > I say this as a FYI fact only, not implying anything.
> > Make of it what you want.
> >
> > - Ben
> >
> > Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák
> > :
> > >
> > > Howdy,
> > >
> > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> > > majority of Maven users do not run Maven on the same Java version they
> > > target with their build. We do not do that either.
> > >
> > > Some snippets from Herve (who is the ONLY one doing reproducible
> checks,
> > > kudos for that) votes:
> > >
> > > Sun, Feb 18, 2024, 9:38 AM
> > > [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> > > Reproducible Build ok: reference build done with JDK 11 on *nix
> > >
> > > Wed, Jan 31, 2024, 5:06 AM
> > > [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> > umask
> > > 022
> > >
> > > Mon, Jan 8, 2024, 8:29 AM
> > > [VOTE] Release Maven Plugin Tools version 3.11.0
> > > Reproducible Builds ok: reference build done with JDK 8 on Windows with
> > > umask
> > >
> > > Mon, Dec 18, 2023, 8:59 AM
> > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> > umask
> > > 022
> > >
> > > Mon, Dec 18, 2023, 8:59 AM
> > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> > umask
> > > 022
> > >
> > > Wed, Nov 29, 2023, 8:16 AM
> > > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > > Reproducible Build ok: reference build done on *nix with JDK 11
> > >
> > > Sun, Nov 19, 2023, 5:17 PM
> > > [VOTE] Release Maven Resolver 1.9.17
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > umask
> > > 022
> > >
> > > Sat, Oct 21, 2023, 4:34 PM
> > > VOTE] Apache Maven 4.0.0-alpha-8 release
> > > Reproducible Build ok: reference build done with JDK 21 on *nix with
> > umask
> > > 022
> > >
> > > Mon, Oct 2, 2023, 9:11 AM
> > > [VOTE] Release Apache Maven 3.9.5
> > > Reproducible not fully ok: reference build done with JDK 17 on *nix and
> > > umask 022
> > >
> > > 
> > >
> > > This CLEARLY shows the tendency:
> > > - Michael does releases on Java 8 (on windows!), he is a known
> "aligner"
> > > and windows person :)
> > > - Olivier used the "minimum" required Java version (for build cache).
> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he
> could
> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> > release.
> > > - The rest is 21.
> > >
> > > 
> > >
> > > So, the question for those refusing anything other than Java 8 to _run_
> > > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> > that
> > > is currently 21):
> > > WHY?
> > >
> > >
> > > Thanks
> > > T
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
java_version,version_count
Java 1.8.0_382,1393438
Java 17.0.10,1001367
Java 17.0.9,570622
Java 21.0.2,529117
Java 21.0.1,283869
Java 11.0.22,278228
Java 17.0.7,268306
Java 17.0.8.1,259908
Java 11.0.21,240155
Java 17.0.2,180392
Java 17.0.8,145560
Java 17.0.6,139473
Java 1.8.0_292,138687
Java 1.8.0_392,121122
Java 1.8.0_402,117920
Java 19.0.2,110573
Java 17.0.5,108176
Java 1.8.0_342,98935
Java 11.0.16,93427
Java 11.0.10,85030
Java 21,84248
Java 20.0.2,80392
Java 17.0.1,77423
Java 11.0.14.1,66802
Java 11.0.11,63485
Java 11.0.19,59590
Java 20.0.1,58030
Java 18.0.2.1,57879
Java 11.0.20,55293
Java 1.8.0_202,51614
J

Re: Feature Request: Add CPE String to pom.xml

[Brian Fox]

Hi Sebastian,

The challenge is that CPE as a coordinate system doesn’t have enough
specificity to match artifacts. It has organization/product/version and
therefore doesn’t have the ability to capture sub module. This is what
leads to most of the mismatch issues seen in CVE based tools (but not all
tools have this problem).

Since the coordinates for CPE don’t have enough parts, it’s not clear to me
how recording it in the Pom changes anything. Alas if the CPE was coded
into the Pom, it almost certainly would be derived from the coordinates
anyway and therefore really shouldn’t even have to be repeated.

On Tue, Mar 15, 2022 at 7:12 AM Sebastian Stenzel <
sebastian.sten...@gmail.com> wrote:

> Hi,
>
> I'm new on this mailing list and this might not be the appropriate place
> to discuss ideas to extend the pom format, so please redirect me to the
> right place ;-)
>
> We've recently had a lot of struggles with both false positives and false
> negatives with a vulnerability scanner, as there is no reliable way to
> derive a CPE string from Maven dependencies. This is mostly caused by the
> fact that groupIds and artifactIds can not be literally translated into CPE
> organization and product strings. In many cases, the product name is also
> the groupId (e.g. Jetty) with lots of artifacts being published under this
> groupId. Now a vulnerability in jetty:jetty might not affect
> jetty:jetty-util, however probabilistic CPE matching algorithms will still
> report a false positive.
>
> Now one could argue that this is a problem of the vulnerability checker (I
> agree), however the only means they have is changing the confidence
> threshold (which would cause false negatives, defying the purpose) or
> maintaining an ever-growing list of false positives. Both are mere
> workarounds.
>
> What could really solve this: Replacing those fuzzy matching algorithms,
> if there was a reliable way to determine the CPE string from a library.
> Ideally the library would carry this in its metadata itself. We could add
> custom properties to the pom.xml or the MANIFEST.MF, but I believe that
> adoption would benefit if there was an official standard.
>
> Given that both published Maven artifacts as well as reported CVEs will
> only grow over time and the importance of correctly identifying
> vulnerabilities is no longer denied by anyone (at least not since
> log4shell), I hope CPE strings will find their place in official package
> metadata (not only in Maven). Can this be considered in the next pom xsd?
>
> Cheers!
> Sebastian
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

CVE-2021-26291: Apache Maven: block repositories using http by default

[Brian Fox]

Apache Maven may follow repositories that are defined in a
dependency’s Project Object Model (pom) which may be surprising to
some users, resulting in potential risk if a malicious actor takes
over that repository or is able to insert themselves into a position
to pretend to be that repository. Maven is changing the default
behavior to no longer follow http (non-SSL) repository references by
default in version 3.8.1

Details:

Apache Maven uses pom files as descriptors to build software and
declare dependencies. The pom files can contain references such as
plugins and configuration to be used for compilation, testing,
packaging etc, as well as a list of dependencies.


Each dependency itself is also expected to contain basic information,
including its own dependencies, allowing a transitive dependency tree
to be calculated and resolved as needed. In cases where dependencies
are not located in a default repository, a reference to an additional
repository where the dependencies can be resolved may be included in
the pom.


There are two distinct use cases for how repositories defined in poms are used:


When building a project that has a pom.xml file on disk that
references a repository, the repository reference takes precedence
over previous configuration. This is to be expected since in this
mode, one should consider the declaration to be an explicit
instruction as part of the build process.

When building a project that depends upon a dependency which
references a remote repository, things work differently. In this
instance, the remote repository is added at the end of the search list
and is scoped such that only dependencies of the pom referencing it
may be retrieved from this referenced repository. This capability has
existed in Maven since the beginning, because without the pointer to
the location of these dependencies, a consumer’s build is going to
fail. Since the repository was defined in the pom for use case #1 (ie
at build time), it made sense to allow it to be automatically
referenced during use case #2 (ie at dependency consume time).


The order in which repositories are searched is documented at
https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order.


The issue at hand is that although users should always understand code
they depend upon or reuse, many consumers of dependencies do not
inspect the poms. Those users may not be aware that a pom can point
their build at yet another repository to fetch dependencies and their
poms.


With this ability for 3rd party pom authors to point a build to a new
location, it creates an opportunity for a malicious actor to direct
builds to fetch dependencies from this untrusted repository. There is
the additional possibility that a bad actor could take over an
abandoned repository url. If the attackers are in a privileged
location on the network, they could additionally exploit the lack of
ssl encryption over legacy repository definitions and attempt a Man In
The Middle (mitm) attack to insert malicious components.


Given the fact that the average consumer of dependencies may not
inspect poms for remote repositories and may not have other
compensating mechanisms in place, the Maven project has decided to
harden the default behavior in version 3.8.1 and above in the
following ways:


 (MNG-7117): A new block parameter is added to the settings.xml mirror
section. This allows a user to define a particular url that should
never be accessed by setting block = true.


(MNG-7116): A new external:http:* pattern is added to the mirrorOf
field that allows a user to redirect or, in combination with the above
block setting, block any repository reference that is not using ssl.
In combination, with the existing negation patterns, this would allow
users to selectively allow certain trusted repositories while blocking
all others. See here for more information on these patterns: Maven –
Guide to Mirror Settings


Finally, (MNG-7118) we have added a new entry to the default
conf/settings.xml which will automatically create a mirror of
external:http:* with block set to true. This will have the effect of
blocking all http repository references by default. Detailed release
notes can be found at
https://maven.apache.org/docs/3.8.1/release-notes.html


While this hardening limits the impact of external repositories
introduced by dependencies by only allowing ssl secured urls, and the
scope of dependency resolution is limited such that these external
repositories are searched a) last and b) only for dependencies in the
pom where it was introduced, it does not completely eliminate all
possible future attack vectors.


For absolute control over the repositories used by Maven, the
longstanding best practice for management of dependency resolution and
allowed repositories has been to use a repository manager. The typical
mechanism for enabling this mode of operation has Maven config set to
override all repository definitions (for both use case 1 and 2) 

Re: [VOTE] Release Apache Maven version 3.8.0

[Brian Fox]

I'm +1. If the worst thing we can find to worry about is the version
number 3.7, 3.8, then it seems like we're close enough.

On Wed, Mar 24, 2021 at 3:11 AM Romain Manni-Bucau
 wrote:
>
> +0 cause of the versioning which is unexpected (but you know what? since it
> is a git tag we can drop it and recreate it since only the hash is used and
> not the name so we can do the 3.7.0 ;)).
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mer. 24 mars 2021 à 07:47, Hervé BOUTEMY  a
> écrit :
>
> > you know what? now that the tag is done, we can't revert :)
> >
> > Le mercredi 24 mars 2021, 01:58:19 CET Olivier Lamy a écrit :
> > > +0
> > > Same reason as Ralph, the versioning seems weird to me.
> > > I don't understand the reasoning of version number. Our version number
> > > doesn't have to be managed by some tweet or google links.
> > >
> > >
> > > On Wed, 24 Mar 2021 at 09:17, Ralph Goers 
> > >
> > > wrote:
> > > > If I were a user and expected the feature to be in 3.7.0 then I would
> > > > certainly also expect it in 3.8.0. The only ways to avoid this are a)
> > stay
> > > > on 3.6.x.x until the feature is available, b) specifically say the
> > > > promised
> > > > features aren’t available yet.
> > > >
> > > > That said I’m +0 on the version numbering.
> > > >
> > > > Ralph
> > > >
> > > > > On Mar 22, 2021, at 3:09 PM, Robert Scholte 
> > > >
> > > > wrote:
> > > > > There were enough tweets and conference talks were I demonstrated the
> > > >
> > > > idea behind build/consumer.
> > > >
> > > > > Of course the audience wanted to hear a version, so the best possible
> > > >
> > > > answer was "most likely 3.7.0"
> > > >
> > > > > First Google hit: Maven 3.7 to Include Default Wrapper - InfoQ[1] and
> > > >
> > > > you can find much more.
> > > >
> > > > > Several PMC members discussed about what would be the proper value,
> > the
> > > >
> > > > result was in the end 3.8.0.
> > > >
> > > > > Most important: it is beyond 3.6.3 and before 4.
> > > > >
> > > > > Robert
> > > > >
> > > > > [1] https://www.infoq.com/news/2020/04/maven-wrapper/
> > > > >
> > > > > On 22-3-2021 21:14:10, Elliotte Rusty Harold 
> > wrote:
> > > > > I'm a weak -1 on this, solely because I don't find the reasoning for
> > > > > not calling this 3.7.0 to be compelling. "Apache Maven 3.7.0 would be
> > > > > the first release where you could optionally activate the
> > > > > build/consumer feature. This version of this release has been renamed
> > > > > to 4.0.0. Reusing 3.7.0 might lead to confusion, hence we picked the
> > > > > next available minor version."
> > > > >
> > > > > Are we sure? I certainly didn't expect 3.7.0 to be the first release
> > > > > where you could optionally activate the build/consumer feature. I
> > > > > can't say I expected anything in particular for 3.7.0. Did Maven ever
> > > > > promise there would be a 3.7.0 with this feature?
> > > > >
> > > > > If it were renamed 3.7.0 I'd be at +1.
> > > > >
> > > > > On Mon, Mar 22, 2021 at 7:40 PM Robert Scholte wrote:
> > > > >> Hi,
> > > > >>
> > > > >> For the details about this release, please read
> > > >
> > > > https://maven.apache.org/docs/3.8.0/release-notes.html
> > > >
> > > > >> Also please provide feedback on the release notes. (as you know,
> > these
> > > >
> > > > are published separately from the release, so it doesn't have to block
> > the
> > > > release itself)
> > > >
> > > > >> We solved 5 issues:
> > > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&;
> > > > version=12350003&styleName=Text>
> > > > >> There are still a couple of issues left in JIRA:
> > > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012316922%20AND%
> > > >
> > 20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20
> > > > DESC>
> > > > >> Staging repo:
> > > > >> https://repository.apache.org/content/repositories/maven-1633/
> > > >
> > > >
> > https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/binaries/ap
> > > > ache-maven-3.8.0-bin.zip
> > > >
> > > >
> > https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/source/apac
> > > > he-maven-3.8.0-src.zip>
> > > > >> Source release checksum(s):
> > > >
> > > > >> apache-maven-3.8.0-bin.zip sha512:
> > > >
> > b56da9a0efa45e084e4882b795787fc7b61970d19835635b2db099b91a9854f14e3776a01d
> > > > 569e3f7af9db946a05af91abbfad41cdc5ac09e90df25077dec01e>
> > > > >> apache-maven-3.8.0-src.zip sha512:
> > > >
> > 51a1570894e8fb1ef52cb19ce472866745ccae2720e45304edd3cabc212cdf105937c76502
> > > > 558fe87995aea81c41402d7f581cc8e9393af234b64696e9a45893>
> > > > >> Staging site:
> > > > >> https://maven.apache.org/ref/3-LATEST/
> > > > >>
> > > >

Re: [VOTE] Release Apache Maven version 3.8.0

[Brian Fox]

The CVE is for documentation and the hardening of default behavior,
it's not your typical zero day.

On Mon, Mar 22, 2021 at 10:53 PM Gary Gregory  wrote:
>
> You are acknowledging a CVE _before_ a release?
>
> Gary
>
>
> On Mon, Mar 22, 2021, 15:40 Robert Scholte  wrote:
>
> > Hi,
> >
> > For the details about this release, please read
> > https://maven.apache.org/docs/3.8.0/release-notes.html
> > Also please provide feedback on the release notes. (as you know, these are
> > published separately from the release, so it doesn't have to block the
> > release itself)
> >
> > We solved 5 issues:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12350003&styleName=Text
> >
> > There are still a couple of issues left in JIRA:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012316922%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1633/
> >
> >
> > https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/binaries/apache-maven-3.8.0-bin.zip
> >
> > https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0/source/apache-maven-3.8.0-src.zip
> >
> >
> > Source release checksum(s):
> >
> > apache-maven-3.8.0-bin.zip sha512: 
> > b56da9a0efa45e084e4882b795787fc7b61970d19835635b2db099b91a9854f14e3776a01d569e3f7af9db946a05af91abbfad41cdc5ac09e90df25077dec01e
> >
> > apache-maven-3.8.0-src.zip sha512: 
> > 51a1570894e8fb1ef52cb19ce472866745ccae2720e45304edd3cabc212cdf105937c76502558fe87995aea81c41402d7f581cc8e9393af234b64696e9a45893
> >
> >
> > Staging site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: uploading to central via ossrh is problematic

[Brian Fox]

I think that each of those other instances are more unrelated to each
other, except in some cases massive scale. OSSRH itself is in the
process of being federated and large projects are given the
opportunity to move to their own new, or separate instance so their
load doesn't hurt the many thousands of other builds flowing through
the system at any given time. In terms of the community though, this
list is really the place to discuss development of maven itself, so
it's a bit orthogonal.

On Thu, Jan 21, 2021 at 1:43 PM Matthieu Brouillard
 wrote:
>
> Thanks Brian,
>
> I'll reopen an issue next time I face an upload problem.
>
>
> *> it's not occurring across the entire system *
> Ok but the case was not isolated, it occurred also in the past weeks to
> microsoft, redhat, springboot guys and to several anonymous like me that
> try to maintain some oss stuff.
> Moreover, I initially thought that OSSRH timeout was not 'just' a Sonatype
> issue even if Sonatype is the operator of central & OSSRH (and I thank you
> for that). I saw it as a community problem and thus I just wanted to have
> some feedback from this community.
>
> Matthieu
>
>
>
> On Thu, Jan 21, 2021 at 6:25 PM Brian Fox  wrote:
>
> > Hi Matthieu, I think continuing the conversation on your existing
> > ossrh ticket is the right place to resolve this. While it seems like
> > you're having recurring issues, it's not occurring across the entire
> > system so we need to figure out what the unique issue is.
> >
> > --Brian
> > Cofounder & CTO Sonatype
> >
> > On Thu, Jan 21, 2021 at 7:28 AM Matthieu Brouillard
> >  wrote:
> > >
> > > Hello,
> > >
> > > Can a representative provide some information on the topic. Are there
> > > discussions with Sonatype?
> > > Yesterday again OSSRH had troubles [1].
> > > The graphs on https://status.maven.org/ can look ok but I suspect the
> > > 99.99% of OSSRH availability to be only an HTTP health check which does
> > not
> > > represent the effective availability of the service (the staging
> > operation
> > > duration is by far a better indicator but data is restricted to a single
> > > day and the holes in the graph are not explained).
> > > Such recurring issues should be tackled otherwise people will switch to
> > > less reliable (in term of ownership / deployment rules) alternative
> > > repositories and libraries/projects will not reach central anymore.
> > >
> > > Regards,
> > >
> > > Matthieu
> > >
> > > [1] : https://status.maven.org/incidents/c9svd46b6r92?u=hj0q9bssz3zp
> > >
> > > On Thu, Jan 14, 2021 at 12:13 PM Matthieu Brouillard <
> > matth...@brouillard.fr>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I know the issue/problem below is not directly related to maven dev
> > list
> > > > but I thought it would be a good place to open the discussion.
> > > >
> > > > It has been the case for several months now : community is facing
> > issues
> > > > when deploying to central via OSSRH.
> > > > Personally I faced the issue several times, latest one today
> > > > (OSSRH-63407). I reached them via twitter and commented on open issues.
> > > > Also Microsoft JDBC team faced it few weeks ago (OSSRH-62435), Quarkus
> > > > team is having problems too (OSSRH-63387) and some others : see JIRA
> > search
> > > > [1]
> > > >
> > > > As going through OSSRH is the official documented way [2] to reach
> > central
> > > > and as it affects the community, don't you think there should be some
> > > > discussions between maven representatives & sonatype ones to tackle the
> > > > problems?
> > > >
> > > > Regards,
> > > >
> > > > Matthieu
> > > >
> > > > [1] :
> > > >
> > https://issues.sonatype.org/browse/OSSRH-63387?jql=project%20%3D%20OSSRH%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20created%20%3E%3D%20-10w%20AND%20text%20~%20%22timeout%20OR%20slow%22%20ORDER%20BY%20priority%20DESC%2C%20created%20DESC%2C%20updated%20DESC
> > > > [2] :
> > > >
> > https://maven.apache.org/repository/guide-central-repository-upload.html
> > > >
> >
> > -
> > 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: uploading to central via ossrh is problematic

[Brian Fox]

Hi Matthieu, I think continuing the conversation on your existing
ossrh ticket is the right place to resolve this. While it seems like
you're having recurring issues, it's not occurring across the entire
system so we need to figure out what the unique issue is.

--Brian
Cofounder & CTO Sonatype

On Thu, Jan 21, 2021 at 7:28 AM Matthieu Brouillard
 wrote:
>
> Hello,
>
> Can a representative provide some information on the topic. Are there
> discussions with Sonatype?
> Yesterday again OSSRH had troubles [1].
> The graphs on https://status.maven.org/ can look ok but I suspect the
> 99.99% of OSSRH availability to be only an HTTP health check which does not
> represent the effective availability of the service (the staging operation
> duration is by far a better indicator but data is restricted to a single
> day and the holes in the graph are not explained).
> Such recurring issues should be tackled otherwise people will switch to
> less reliable (in term of ownership / deployment rules) alternative
> repositories and libraries/projects will not reach central anymore.
>
> Regards,
>
> Matthieu
>
> [1] : https://status.maven.org/incidents/c9svd46b6r92?u=hj0q9bssz3zp
>
> On Thu, Jan 14, 2021 at 12:13 PM Matthieu Brouillard 
> wrote:
>
> > Hi all,
> >
> > I know the issue/problem below is not directly related to maven dev list
> > but I thought it would be a good place to open the discussion.
> >
> > It has been the case for several months now : community is facing issues
> > when deploying to central via OSSRH.
> > Personally I faced the issue several times, latest one today
> > (OSSRH-63407). I reached them via twitter and commented on open issues.
> > Also Microsoft JDBC team faced it few weeks ago (OSSRH-62435), Quarkus
> > team is having problems too (OSSRH-63387) and some others : see JIRA search
> > [1]
> >
> > As going through OSSRH is the official documented way [2] to reach central
> > and as it affects the community, don't you think there should be some
> > discussions between maven representatives & sonatype ones to tackle the
> > problems?
> >
> > Regards,
> >
> > Matthieu
> >
> > [1] :
> > https://issues.sonatype.org/browse/OSSRH-63387?jql=project%20%3D%20OSSRH%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20created%20%3E%3D%20-10w%20AND%20text%20~%20%22timeout%20OR%20slow%22%20ORDER%20BY%20priority%20DESC%2C%20created%20DESC%2C%20updated%20DESC
> > [2] :
> > https://maven.apache.org/repository/guide-central-repository-upload.html
> >

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Moving hashes (checksums) forward

[Brian Fox]

As will all things Maven and Central, we must consider the long tail
of versions in use. It's not going to work to flip a switch and fork
the community over updated hashes. Instead the role of Maven here
should be first to enable the new hashes but it shouldn't blow up if a
given upstream tool can't consume or produce the new hashes.

We were planning on doing some full system walks and validations on
Central in the near future for different reasons, I'll see if it's
possible to generate new hashes at the same time. I would only want to
publish updated sha2 hashes if the original sha1 hash was proper, I
don't think burying the broken hash is a good idea without subsequent
investigation.

On Sun, May 31, 2020 at 4:51 PM Michael Osipov  wrote:
>
> Am 2020-05-31 um 17:19 schrieb Robert Scholte:
> > hi,
> >
> > I would be great if Sonatype could lead this request.
> > It seems like a similar process compared to the TLSv1.2 requirement and the 
> > drop of http
> > They have the best overview in how to handle the switch to different hashes.
> > You can already start with #1, but until then I would be careful with #2
>
> #2 can't be done w/o careful planning. That's clear.
> Who's the right contact at Sonatype? Brian Fox?
>
>
> > On 31-5-2020 16:58:58, Michael Osipov  wrote:
> > Folks,
> >
> > I have been recently (indirectly) approached by Mark Thomas for the
> > Tomcat committers that he wants to provide SHA-2 hashes for all uploaded
> > Tomcat artifacts in Central. Since Nexus 2.14.18 supports this properly
> > for validation, I have picked up MRESOLVER-56 and asked for testing.
> >
> > I'd like also to discuss two proposals for the Maven community:
> > 1. Introduce SHA-2 support in Maven Resolver 1.4.3 which will go into
> > Maven 3.7.0
> > 2. Deprecate MD5 and SHA-1 with that release and make them obsolete with
> > Maven 4.0 and Maven Resolver 2.0 which will include package change also.
> >
> >
> > Those proposals have the following greater implications:
> > 1.
> > * Certain repo managers might reject hashes, they don't know. As did
> > Nexus on repository.a.o.
> > * This will incur two more requests with each upload and download. In
> > the latter, it will fail with 404 because most repo managers won't have
> > SHA-2 hashes. So fails Central for now. (will be solved with 2.)
> >
> > 2.
> > * All repo managers will need to
> > ** rehash all current content to provide SHA-2 hashes
> > ** Require SHA-2 hashes to be uploaded
> > ** Reject MD5 and SHA-1 hashes
> > * Old tools will fail because MD5 and SHA-1 hashes are gone:
> > ** Uploads will be rejected
> > ** Strict download validation will fail
> >
> > Please comment. I will also provide a draft PR soon.
> > I can cast two formal votes if required.
> >
> > Michael
> >
> > -
> > 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

Deprecating HTTP access to Central

[Brian Fox]

Last year, we deprecated old and insecure TLS protocols on Central to
make access more secure. This year, we're moving things forward again
by deprecating and later removing access to insecure by default HTTP
access.

Right now this affects less than 20% of the traffic hitting Central.
To find out more about the timelines and details, see here:
https://central.sonatype.org/articles/2019/Apr/30/http-access-to-repo1mavenorg-and-repomavenapacheorg-is-being-deprecated/

Thanks,
Brian
CTO, Sonatype
Apache Maven PMC Member

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[Notice] Java 6 and 7 users: TLS 1.1 being discontinued on Central

[Brian Fox]

In June, in an effort to raise security and comply with modern
standards, the insecure TLS 1.1 protocol will no longer be supported
for SSL connections to Central. This should only affect users of Java
6 that are also using https to access central, which by our metrics is
less than .2% of users.

Some early versions of Java 7 will need parameters to enable TLS 1.2.

The details about why, when and what you need to do are documented at
the link below. As questions come up, we will continue to update this
faq.

If there is specific information required for non-maven build systems,
please send it along and we will include that as well.

https://central.sonatype.org/articles/2018/May/04/discontinue-support-for-tlsv11-and-below/

--Brian Fox
Apache Maven PMC
CTO, Sonatype

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Indexer 6.0.0

[Brian Fox]

On Fri, Dec 1, 2017 at 3:19 AM, Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:

> Olivier Lamy wrote:
> > probably no issues for sure.
> > I just don't know if we will be able to still download the index from
> > central and use it with this new version
> > TBH I haven't done any testing etc so it's just questions :-)
>
> FYI, my testing included downloading the index from Central (to be
> precise: its uk.maven.org mirror)


fwiw this all just points to the fastly cdn these days, so it's the same
thing you'll get using repo1.maven.org. (this url goes back to pre cdn when
we did actually have separate physical systems.



> with the staged Indexer 6.0.0. So, the
> current code its able to consume the index currently produced for
> Central, presumably by Indexer 5.x.
>
> Hope that helps.
>
> Best wishes,
>
> Andreas
>
>

Re: [VOTE] Release Maven Indexer 6.0.0

[Brian Fox]

Eyeballing the list, most of the changes seem irrelevant to the central use
case. Is there anything in here that matters for Central (and if so, what
are the backwards compat implications?)

On Thu, Nov 30, 2017 at 2:07 AM, Olivier Lamy  wrote:

> +1
>
> I'm not clear if this new version will be used for Central?
>
> On 28 November 2017 at 21:20, Tamás Cservenák  wrote:
>
> > [VOTE] Release Maven Indexer 6.0.0
> >
> > Hi,
> >
> > We solved 25 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12317523&version=12330802
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/projects/MINDEXER/issues/
> > MINDEXER-81?filter=allopenissues
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1379
> > https://repository.apache.org/service/local/repositories/
> > maven-1379/content/org/apache/maven/indexer/maven-indexer/6.
> > 0.0/maven-indexer-6.0.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-indexer-6.0.0-source-release.zip sha1:
> > 279939f8deff0f5518364c06da847b32ab6108ed
> >
> > Staging site:
> > http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > --
> > Thanks,
> > ~t~
> >
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Maven JDeprScan Plugin

[Brian Fox]

All set.

On Sat, Oct 28, 2017 at 9:48 AM, Robert Scholte 
wrote:

> Hi,
>
> I'd like to prepare an alpha release of the Maven JDeprScan Plugin
> It is a wrapper around the jdeprscan tool[1], available since Java 9.
>
>   You use the jdeprscan tool as a static analysis tool that scans a jar
> file (or some other aggregation of class files) for uses of deprecated API
> elements.
>
> It would be nice if some could a review upfront. Any feedback it
> appreciated.
>
> @Brian, can you create a new Jira project: MJDEPRSCAN ?
>
> thanks,
> Robert
>
> [1] https://docs.oracle.com/javase/9/tools/jdeprscan.htm
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: dependency:go-offline broken?

[Brian Fox]

No, I don't think it will work. What you really need is a repository
manager to cache things locally for you. That's the recommended solution
any time you feel like you're going to be downloading components more than
once...which is really in every instance.

On Wed, Sep 27, 2017 at 7:53 AM, Benedikt Ritter  wrote:

> Hello Brain,
>
> > Am 26.09.2017 um 23:10 schrieb Brian Fox :
> >
> > On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter 
> wrote:
> >
> >> Hello Brian,
> >>
> >>> Am 20.09.2017 um 23:16 schrieb Brian Fox :
> >>>
> >>> It's been a really long time, but I recall that there were issues
> getting
> >>> the dependencies of plugins bound to the lifecycle. This looks to be
> the
> >>> same problem. I think the documentation talked about a way to do this
> >>> effectively.
> >>
> >> I’ve looked through the documentation of the dependency plugin, but I
> can
> >> not find anything about this. Do you recall where you found that
> >> documentation?
> >>
> >>
> > Ha no, since I wrote that goal 10 years ago I'm scratching the depth of
> my
> > memory. Maybe I just intended to describe it ;-)
>
> Thank you for your response. Maybe I’ll just give a little more context
> about what I’m trying to achieve. Maybe I’m just doing the wrong thing:
>
> I have a CI Build in GitLab, where I want to define a job that downloads
> all the artifacts which are needed for the different lifecycle phases and
> plugin executions as well as all project dependencies. I only want to
> download all the stuff once and then copy the artifacts between the build
> stages. I thought this would be possible with dependency:go-offline so that
> later steps can be run with mvn -o.
> Am I missing something or is this simply not possible at the moment?
>
> Regards,
> Benedikt
>
> >
> >
> >> Regards,
> >> Benedikt
> >>
> >>>
> >>> On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter 
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> as far as I understand it should be possible to call mvn
> >>>> dependency:go-offline and from there on work in offline mode (mvn -o).
> >>>> I’ve put a minimal example together [1] that demonstrates that this
> >>>> currently does not work. Am I missing anything?
> >>>>
> >>>> Thank you!
> >>>> Benedikt
> >>>>
> >>>> [1] https://github.com/britter/dependency-plugin-bug
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>
> >>>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: dependency:go-offline broken?

[Brian Fox]

On Mon, Sep 25, 2017 at 2:10 PM, Benedikt Ritter  wrote:

> Hello Brian,
>
> > Am 20.09.2017 um 23:16 schrieb Brian Fox :
> >
> > It's been a really long time, but I recall that there were issues getting
> > the dependencies of plugins bound to the lifecycle. This looks to be the
> > same problem. I think the documentation talked about a way to do this
> > effectively.
>
> I’ve looked through the documentation of the dependency plugin, but I can
> not find anything about this. Do you recall where you found that
> documentation?
>
>
Ha no, since I wrote that goal 10 years ago I'm scratching the depth of my
memory. Maybe I just intended to describe it ;-)


> Regards,
> Benedikt
>
> >
> > On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter 
> wrote:
> >
> >> Hi,
> >>
> >> as far as I understand it should be possible to call mvn
> >> dependency:go-offline and from there on work in offline mode (mvn -o).
> >> I’ve put a minimal example together [1] that demonstrates that this
> >> currently does not work. Am I missing anything?
> >>
> >> Thank you!
> >> Benedikt
> >>
> >> [1] https://github.com/britter/dependency-plugin-bug
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: dependency:go-offline broken?

[Brian Fox]

It's been a really long time, but I recall that there were issues getting
the dependencies of plugins bound to the lifecycle. This looks to be the
same problem. I think the documentation talked about a way to do this
effectively.

On Wed, Sep 20, 2017 at 4:48 PM, Benedikt Ritter  wrote:

> Hi,
>
> as far as I understand it should be possible to call mvn
> dependency:go-offline and from there on work in offline mode (mvn -o).
> I’ve put a minimal example together [1] that demonstrates that this
> currently does not work. Am I missing anything?
>
> Thank you!
> Benedikt
>
> [1] https://github.com/britter/dependency-plugin-bug
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven BOF session @ JavaOne

[Brian Fox]

Cool. I'll be there as well.

On Sat, Jul 29, 2017 at 5:58 AM, Robert Scholte 
wrote:

> Hi,
>
> Both my talk and the BOF have been accepted for JavaOne 2017.
> I will host the BOF session together with Manfred Moser.
> All are invited to join.
>
>
> thanks,
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

index out of bounds 3.5 regression

[Brian Fox]

I'm getting index out of bounds exceptions with 3.5 that don't occur with
3.3.9. I haven't debugged it yet, but wondering if this is already known?
Fwiw reproducible with the DependencyCheck 2.0-snapshot master.

[ERROR] 13978

java.lang.ArrayIndexOutOfBoundsException: 13978

at org.codehaus.plexus.util.xml.pull.MXParser.parsePI(MXParser.java:2502)

at
org.codehaus.plexus.util.xml.pull.MXParser.parseEpilog(MXParser.java:1604)

at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1434)

at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1131)

at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:3856)

at
org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:595)

at
org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:109)

at
org.apache.maven.model.io.DefaultModelReader.read(DefaultModelReader.java:82)

at
org.apache.maven.model.building.DefaultModelProcessor.read(DefaultModelProcessor.java:81)

at
org.apache.maven.model.building.DefaultModelBuilder.readModel(DefaultModelBuilder.java:535)

at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:275)

at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:321)

at
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:199)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.resolveCachedArtifactDescriptor(DefaultDependencyCollector.java:544)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.getArtifactDescriptorResult(DefaultDependencyCollector.java:528)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:418)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:372)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:360)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.doRecurse(DefaultDependencyCollector.java:513)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:467)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:372)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:360)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.doRecurse(DefaultDependencyCollector.java:513)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:467)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency(DefaultDependencyCollector.java:372)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.process(DefaultDependencyCollector.java:360)

at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:263)

at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:325)

at
org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolveInternal(DefaultPluginDependenciesResolver.java:202)

at
org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:149)

at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.createPluginRealm(DefaultMavenPluginManager.java:402)

at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.setupPluginRealm(DefaultMavenPluginManager.java:374)

at
org.apache.maven.plugin.DefaultBuildPluginManager.getPluginRealm(DefaultBuildPluginManager.java:231)

at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:102)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)

at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)

at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)

at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)

at sun.reflect.NativeMethodAcce

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

[Brian Fox]

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 
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
>
>

Jigsaw removes the ability for tools to help name transition

[Brian Fox]

Robert and I wrote a bit previously [1] about the issues with the
automodules in jigsaw (hint: they use only the filename to default a module
which we've demonstrated is a terrible idea). There was a happy medium
which would have allowed library developers to select a name before full
modularization. Unfortunately, this has again been removed from the working
spec, and the vote is just around the corner.

I replied with the concerns and vision [2] but it has since been
unanswered. We need more people to speak up on this issue.

Several other EC members worked together to share concerns and this is a
scary read [3], along with another discussion of module names here [4]

[1]
http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/
[2]
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-April/000858.html
[3]
https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns
[4] http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html

Re: Fwd: How to name modules, automatic and otherwise

[Brian Fox]

Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module-Name simply by defaulting
it to g:a and building up a good base of new stuff going into Central such
that when people start using jigsaw, there is a good pattern in place and
we've hopefully avoided conflicts.

Am I mis-understanding your proposal?

On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
wrote:

> tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
> the
> fact that nothing was taken into consideration looked something that was
> happenning (and the recent publication shows that it has happened now)
>
> Then Remi and I discussed and looked for ideas on what lighter proposal to
> do
> for the namespace concern when sharing modules publicly
>
> And I proposed a simplified idea that looked promising when we challenged
> it:
> for modules that are to be shared on Maven Central,
> handwritten full module name should *start with groupId*
>
>
> applied to the example for Hibernate, this would just say: Hibernate
> project
> owns "org.hibernate" module namespace on [Maven] Central since they own
> org.hibernate groupId
>
> Notice: automodules won't give same module names. Automodules are just
> transient automagic values for temporary local work, not for public shared
> work
>
> Notice 2: whatever does not go to [Maven] Central has just other
> conventions.
> Knowing the impact of existing [Maven] Central content, people doing their
> local convention will probably "naturally" think at:
> - immediate compatibility, to be able to consume public artifacts
> - future compatibility, to be able to later publish a private artifact that
> may be later shared as public artifact
>
>
> I started to share this idea (which is not far from initial proposal: just
> not
> about automodule names and not using artifactId)  yesterday with Robert:
> the
> discussion just started, nobody had time yet to write the proposal down and
> share it with a wider audience
>
>
> WDYT?
>
> Regards,
>
> Hervé
>
> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> > And it looks like they are saying .. just add the groupId (or similar
> > namespace) to the modulename. A bit like some artifact repeat the groupId
> > in the artifactId to be specific... seems like a wasted opportunity to
> > define a good usage pattern. The idea of actually supporting same module
> > names for different forks or the same thing is touted as an advantage.
> > Anybody that ever had to debug something like this will know its not an
> > advantage at all .. just simply path to troubleshooting nightmares.
> >
> > I expected as much but I am still disappointed and see lots of trouble
> with
> > this in the future. Maybe it would be good if all Apache project and
> others
> > that are going to publish modules start with using the full namespace in
> > the module name. Problem is of course that the examples I saw so far all
> do
> > NOT do that so we will end up with a mess anyway..
> >
> > Manfred
> >
> > Brian Fox wrote on 2017-02-16 10:42:
> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko 
> wrote:
> > >> Can't we just block auto-named modules from the build? We control
> > >> dependencies and should be able to look inside and barf if we don't
> like
> > >> anything, no?
> > >
> > > Yes but this only applies to things that are modularized. The bigger
> issue
> > > is all the existing stuff that would be used as automodules...first
> they
> > > are already out there and second, there's nothing to see and block.
> > >
> > >> I realize this does not set good defaults for non-maven projects, so
> > >> there will be some friction there, but hopefully maven userbase is big
> > >> enough to create sufficient pressure for non-maven projects to provide
> > >> explicit module names.
> > >
> > > That's exactly my point in originally suggesting to leverage the g:a by
> > > default, but we can do exactly the same thing by injecting the
> Module-Name
> > > asap to build up the right practices before jigsaw takes off.
> > >
> > >> --
> > >> Regards,
> > >> Igor
> > >>
> > >> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> > >> > I generally agree the concerns were mostly ignored. Specifically the
> > >> > dangers in not carefully approaching and setting best practices in
> the
> > >> > name

Re: Fwd: How to name modules, automatic and otherwise

[Brian Fox]

On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko  wrote:

> Can't we just block auto-named modules from the build? We control
> dependencies and should be able to look inside and barf if we don't like
> anything, no?
>

Yes but this only applies to things that are modularized. The bigger issue
is all the existing stuff that would be used as automodules...first they
are already out there and second, there's nothing to see and block.


>
> I realize this does not set good defaults for non-maven projects, so
> there will be some friction there, but hopefully maven userbase is big
> enough to create sufficient pressure for non-maven projects to provide
> explicit module names.
>

That's exactly my point in originally suggesting to leverage the g:a by
default, but we can do exactly the same thing by injecting the Module-Name
asap to build up the right practices before jigsaw takes off.



>
> --
> Regards,
> Igor
>
> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> > I generally agree the concerns were mostly ignored. Specifically the
> > dangers in not carefully approaching and setting best practices in the
> > names, thereby willfully ignoring what happened with NPM.
> >
> > The inclusion of the Module-Name metadata is frankly, more than I
> > expected
> > we would get. I think this does give us something to work with, first by
> > making that defaulted by the Maven plugins and later by enforcing in the
> > repo as appropriate. Using this correctly could help solve some of my
> > initial concerns that we weren't appropriately leveraging the
> > default-effect.
> >
> > PS: those of you who aren't sure what this was all about, see here:
> > http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-
> regarding-auto-modules/
> >
> > On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser
> > 
> > wrote:
> >
> > > I just read it all .. sigh. Looks like our concerns got ignored to me
> > >
> > > Manfred
> > >
> > > Robert Scholte wrote on 2017-02-16 09:23:
> > >
> > > > FYI,
> > > >
> > > > Robert
> > > >
> > > > --- Forwarded message ---
> > > > From: mark.reinh...@oracle.com
> > > > To: jpms-spec-expe...@openjdk.java.net
> > > > Cc:
> > > > Subject: How to name modules, automatic and otherwise
> > > > Date: Thu, 16 Feb 2017 17:48:27 +0100
> > > >
> > > > This note is in reply to the concerns about automatic modules raised
> by
> > > > Robert Scholte and Brian Fox [1], and by Stephen Colebourne and
> others
> > > > [2].  I've collected my conclusions here rather than in separate
> messages
> > > > because there are several distinct yet intertwined issues.
> > > >
> > > > Summary:
> > > >
> > > >- Module names should not include Maven group identifiers, because
> > > >  modules are more abstract than the artifacts that define them.
> > > >
> > > >- Module names should use the reverse-domain-name-prefix
> convention
> > > >  or, preferably, the project-name-prefix convention.
> > > >
> > > >- We should not abandon automatic modules, since they are a key
> tool
> > > >  for migration and adoption.
> > > >
> > > >- We can address the problems of automatic modules with two fairly
> > > >  minor technical enhancements.
> > > >
> > > > If any of these points strikes you as controversial, please read on!
> > > >
> > > >* * *
> > > >
> > > > Module names should not include Maven group identifiers, as Robert
> > > > Scholte and Brian Fox suggest [1], even for modules declared
> explicitly
> > > > in `module-info.java` files.  Modules in JPMS are a construct of the
> Java
> > > > programming language, implemented in both the compiler and the
> virtual
> > > > machine.  As such, they are more abstract entities than the artifacts
> > > > that define them.  This distinction is useful, both conceptually and
> > > > practically, hence module names should remain more abstract.
> > > >
> > > > This distinction is useful conceptually because it makes it easier,
> as
> > > > we read source code, to think clearly about the nature of a module.
> We
> > > > can reason about a module's dependences, exports, services, and so
> forth
> >

Re: Fwd: How to name modules, automatic and otherwise

[Brian Fox]

I generally agree the concerns were mostly ignored. Specifically the
dangers in not carefully approaching and setting best practices in the
names, thereby willfully ignoring what happened with NPM.

The inclusion of the Module-Name metadata is frankly, more than I expected
we would get. I think this does give us something to work with, first by
making that defaulted by the Maven plugins and later by enforcing in the
repo as appropriate. Using this correctly could help solve some of my
initial concerns that we weren't appropriately leveraging the
default-effect.

PS: those of you who aren't sure what this was all about, see here:
http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/

On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser 
wrote:

> I just read it all .. sigh. Looks like our concerns got ignored to me
>
> Manfred
>
> Robert Scholte wrote on 2017-02-16 09:23:
>
> > FYI,
> >
> > Robert
> >
> > --- Forwarded message ---
> > From: mark.reinh...@oracle.com
> > To: jpms-spec-expe...@openjdk.java.net
> > Cc:
> > Subject: How to name modules, automatic and otherwise
> > Date: Thu, 16 Feb 2017 17:48:27 +0100
> >
> > This note is in reply to the concerns about automatic modules raised by
> > Robert Scholte and Brian Fox [1], and by Stephen Colebourne and others
> > [2].  I've collected my conclusions here rather than in separate messages
> > because there are several distinct yet intertwined issues.
> >
> > Summary:
> >
> >- Module names should not include Maven group identifiers, because
> >  modules are more abstract than the artifacts that define them.
> >
> >- Module names should use the reverse-domain-name-prefix convention
> >  or, preferably, the project-name-prefix convention.
> >
> >- We should not abandon automatic modules, since they are a key tool
> >  for migration and adoption.
> >
> >- We can address the problems of automatic modules with two fairly
> >  minor technical enhancements.
> >
> > If any of these points strikes you as controversial, please read on!
> >
> >* * *
> >
> > Module names should not include Maven group identifiers, as Robert
> > Scholte and Brian Fox suggest [1], even for modules declared explicitly
> > in `module-info.java` files.  Modules in JPMS are a construct of the Java
> > programming language, implemented in both the compiler and the virtual
> > machine.  As such, they are more abstract entities than the artifacts
> > that define them.  This distinction is useful, both conceptually and
> > practically, hence module names should remain more abstract.
> >
> > This distinction is useful conceptually because it makes it easier, as
> > we read source code, to think clearly about the nature of a module.  We
> > can reason about a module's dependences, exports, services, and so forth
> > without cluttering our minds with the details of group identifiers and
> > version constraints.  Today, e.g., we can write, and read:
> >
> >  module foo.data {
> >  exports com.bar.foo.data;
> >  requires hibernate.core;
> >  requires hibernate.jcache;
> >  requires hibernate.validator;
> >  }
> >
> > If we were to extend the syntax of module names to include group
> > identifiers, and encourage people to use them, then we'd be faced with
> > something much more verbose:
> >
> >  module com.bar:foo.data {
> >  exports com.bar.foo.data;
> >  requires org.hibernate:hibernate.core;
> >  requires org.hibernate:hibernate.jcache;
> >  requires org.hibernate:hibernate.validator;
> >  }
> >
> > Group identifiers make perfect sense in the context of a build system
> > such as Maven, where they bring necessary structure to the names of the
> > millions of artifacts available across different repositories.  Such
> > structure is superfluous and distracting in the context of a module
> > system, where the number of relevant modules in any particular situation
> > is more likely to be in the tens, or hundreds, or (rarely) thousands.
> > All else being equal, simpler names are better.
> >
> > At a practical level, the distinction between modules and artifacts is
> > useful because it leaves the entire problem of artifact selection to the
> > build system.  This allows us to switch from one artifact to another
> > simply by editing a `pom.xml` file to adjust a version constraint or a
> > group identifier; if

Re: Unable to close staging repository on repository.apache.org

[Brian Fox]

I looked a little closer, the servers are up and your key 843ddb767188601c
is not there. Make sure you've published your key to the pgp servers and
that you can search it from here: http://pool.sks-keyservers.net:11371/

On Thu, May 26, 2016 at 6:15 PM, Brian Fox  wrote:

> When this happens, it's a failure in the pgp key server ring and despite
> the fact that the ring is meant to distribute load, they all seem to go
> down at the same time. There isn't actually anything we can do on the rao
> side to make this work besides drop the staging rule that checks the key. I
> think we should just wait a bit and see if the ring comes back up.
>
> On Thu, May 26, 2016 at 6:04 PM, Manfred Moser 
> wrote:
>
>> The log of the server shows a lot of connection problems to the key
>> servers.
>>
>> 2016-05-26 09:33:06 INFO  [ool-1-thread-10] -
>> com.sonatype.mercury.plexus.pgp.DefaultPgpVerifier - Had some errors during
>> key retrieval:
>> 843ddb767188601c@http://gpg-keyserver.de/ : Failed (HTTP response
>> code=404, exception Unexpected response status: HTTP/1.1 404 Not Found)
>> 843ddb767188601c@http://pool.sks-keyservers.net:11371/ : Failed (HTTP
>> response code=404, exception Unexpected response status: HTTP/1.1 404 Not
>> found)
>> 843ddb767188601c@http://pgp.mit.edu:11371/ : Failed (HTTP response
>> code=404, exception Unexpected response status: HTTP/1.1 404 Not found)
>>
>> Seems like some sort network issue or so. We have not talked to anyone at
>> ops from Apache that could figure out more from all I know.
>>
>> manfred
>>
>> Jochen Wiedmann wrote on 2016-05-26 14:10:
>>
>> > On Thu, May 26, 2016 at 5:35 PM, Manfred Moser <
>> manf...@simpligility.com>
>> > wrote:
>> >> Seems like a performance/networking glitch. I am talking to Sonatype
>> ops and
>> >> support to get more info/help.
>> >
>> > Could you please forward the conversation to me, Manfred?
>> >
>> > Thanks,
>> >
>> > Jochen
>> >
>> > --
>> > The next time you hear: "Don't reinvent the wheel!"
>> >
>> >
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>> >
>> > -
>> > 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: Unable to close staging repository on repository.apache.org

[Brian Fox]

When this happens, it's a failure in the pgp key server ring and despite
the fact that the ring is meant to distribute load, they all seem to go
down at the same time. There isn't actually anything we can do on the rao
side to make this work besides drop the staging rule that checks the key. I
think we should just wait a bit and see if the ring comes back up.

On Thu, May 26, 2016 at 6:04 PM, Manfred Moser 
wrote:

> The log of the server shows a lot of connection problems to the key
> servers.
>
> 2016-05-26 09:33:06 INFO  [ool-1-thread-10] -
> com.sonatype.mercury.plexus.pgp.DefaultPgpVerifier - Had some errors during
> key retrieval:
> 843ddb767188601c@http://gpg-keyserver.de/ : Failed (HTTP response
> code=404, exception Unexpected response status: HTTP/1.1 404 Not Found)
> 843ddb767188601c@http://pool.sks-keyservers.net:11371/ : Failed (HTTP
> response code=404, exception Unexpected response status: HTTP/1.1 404 Not
> found)
> 843ddb767188601c@http://pgp.mit.edu:11371/ : Failed (HTTP response
> code=404, exception Unexpected response status: HTTP/1.1 404 Not found)
>
> Seems like some sort network issue or so. We have not talked to anyone at
> ops from Apache that could figure out more from all I know.
>
> manfred
>
> Jochen Wiedmann wrote on 2016-05-26 14:10:
>
> > On Thu, May 26, 2016 at 5:35 PM, Manfred Moser  >
> > wrote:
> >> Seems like a performance/networking glitch. I am talking to Sonatype
> ops and
> >> support to get more info/help.
> >
> > Could you please forward the conversation to me, Manfred?
> >
> > Thanks,
> >
> > Jochen
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > -
> > 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: Jira access for new committer

[Brian Fox]

Added simpligility to maven-dev

On Wed, Jun 24, 2015 at 12:38 AM, Barrie Treloar  wrote:
> I've pinged Brian to have a look.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Add Manfred Moser as committer

[Brian Fox]

+1

--mobile

> On May 13, 2015, at 2:55 AM, Hervé BOUTEMY  wrote:
> 
> Hi,
> 
> I'd like to introduce Manfred Moser as committer for the Apache  Maven 
> project.
> 
> He's working on Android Maven plugin for years, has great discussions both on 
> users and dev MLs, has a great attitude.
> And he's just told he wants to improve the site and work on Maven: having him 
> make pull requests is just a waste of energy for both Manfred and whoever 
> will 
> accept the PRs: I'm confident that he'll know when to do changes by himself 
> and 
> when some discussion is necessary before doing the job.
> 
> Vote open for 72H
> 
> [+1]
> [0]
> [-1]
> 
> And here's my +1.
> 
> Hervé
> 
> -
> 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: What binary repo for plexus?

[Brian Fox]

Sorry, I was talking generically about projects using
nexus.codehaus.org not Plexus specifically. Since that's already using
ossrh, there are no implications.

On Tue, Mar 10, 2015 at 3:18 PM, Dennis Lundberg  wrote:
> HI Brian,
>
> Thanks for the input, but now I'm confused.
>
> The POMs for plexus currently points to OSSRH. Can anyone who has done
> a release of a plexus component lately shed some light on where they
> go? Either nexus.codehaus.org och OSSRH.
>
>
> On Tue, Mar 10, 2015 at 6:28 PM, Brian Fox  wrote:
>> The current plan is to continue running nexus.codehaus.org and then
>> move stuff over to ossrh as needed. The ssl cert was just renewed and
>> Bob said the DNS isn't going away immediately. We figure projects have
>> enough other stuff to scurry around changing, Nexus doesn't have to be
>> part of it at the same time. Moving stuff to OSSRH is pretty straight
>> forward when a project is ready to do so.
>>
>> On Tue, Mar 10, 2015 at 7:57 AM, Dennis Lundberg  wrote:
>>> Thanks,
>>>
>>> So currently we deploy to OSSRH?
>>>
>>> I'll let the central support staff know that, so that they can at
>>> least prohibit plexus deploys to nexus.codehaus.org.
>>>
>>> On Tue, Mar 10, 2015 at 11:45 AM, Kristian Rosenvold
>>>  wrote:
>>>> I asked Brian if there was any way to get central publishing rights linked
>>>> to github org membership, much like what we might want for mojo. I did not
>>>> get any specific reply, maybe he'll read this :)
>>>>
>>>> Kristian
>>>>
>>>>
>>>> 2015-03-09 23:33 GMT+01:00 Olivier Lamy :
>>>>
>>>>> AFAIK we have switched deploying directly to ossrh for long time now :-)
>>>>>
>>>>>
>>>>> On 10 March 2015 at 06:01, Dennis Lundberg  wrote:
>>>>>
>>>>> > Hi,
>>>>> >
>>>>> > What is the intended binary repo for plexus, after the move to the
>>>>> > codehaus-plexus organization on github?
>>>>> >
>>>>> > I requested permissions to deploy to ossrh, which is what it says in the
>>>>> > parent. They wanted confirmation that we are switching from
>>>>> > nexus.codehaus.org to ossrh. Are we?
>>>>> >
>>>>> > --
>>>>> > Dennis Lundberg
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olivier Lamy
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>
>>>
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> -
>>> 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
>>
>
>
>
> --
> Dennis Lundberg
>
> -
> 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: What binary repo for plexus?

[Brian Fox]

The current plan is to continue running nexus.codehaus.org and then
move stuff over to ossrh as needed. The ssl cert was just renewed and
Bob said the DNS isn't going away immediately. We figure projects have
enough other stuff to scurry around changing, Nexus doesn't have to be
part of it at the same time. Moving stuff to OSSRH is pretty straight
forward when a project is ready to do so.

On Tue, Mar 10, 2015 at 7:57 AM, Dennis Lundberg  wrote:
> Thanks,
>
> So currently we deploy to OSSRH?
>
> I'll let the central support staff know that, so that they can at
> least prohibit plexus deploys to nexus.codehaus.org.
>
> On Tue, Mar 10, 2015 at 11:45 AM, Kristian Rosenvold
>  wrote:
>> I asked Brian if there was any way to get central publishing rights linked
>> to github org membership, much like what we might want for mojo. I did not
>> get any specific reply, maybe he'll read this :)
>>
>> Kristian
>>
>>
>> 2015-03-09 23:33 GMT+01:00 Olivier Lamy :
>>
>>> AFAIK we have switched deploying directly to ossrh for long time now :-)
>>>
>>>
>>> On 10 March 2015 at 06:01, Dennis Lundberg  wrote:
>>>
>>> > Hi,
>>> >
>>> > What is the intended binary repo for plexus, after the move to the
>>> > codehaus-plexus organization on github?
>>> >
>>> > I requested permissions to deploy to ossrh, which is what it says in the
>>> > parent. They wanted confirmation that we are switching from
>>> > nexus.codehaus.org to ossrh. Are we?
>>> >
>>> > --
>>> > Dennis Lundberg
>>> >
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Compat + Maven 3.0 Plugin Part 1: Mercury

[Brian Fox]

On Sat, Mar 7, 2015 at 10:04 AM, Robert Scholte  wrote:
> Mercury? I guess some of it is now part of Aether,

Mercury predates Aether. It was an attempt to update the artifact apis
that was abandoned. (Unless the name is being reused as something new)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: move maven core to java 7?

[Brian Fox]

+1

On Thu, Mar 5, 2015 at 8:16 AM, Igor Fedorenko  wrote:
> This is chicken-and-egg situation. We won't use java 7 features unless
> the code targets java 7.
>
> Try-with-resources and multi-exception catch are the too features I'd
> like to start using throughout the code. Although not "critical" per se,
> I think they make writing correct maintainable code noticeably easier.
>
> Improvements to standard library, nio in particular, is another big
> reason for me. For example, Files#walkFileTree is significantly faster
> than comparable File-based implementation on large source trees. Knowing
> the core is on java 7 will allow us use that in plexus-utils for example.
>
> Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations
> still use java 6 (and java 5), but the same organizations are not likely
> to move to use latest maven features any time soon either.
>
> --
> Regards,
> Igor
>
>
> On 2015-03-05 7:59, Robert Scholte wrote:
>>
>> I don't know the numbers, but I think JDK6 is still used a lot by the
>> community.
>> Current code builds fine with JDK6.
>> Which JDK7 specific features do you want to use, which are not possible
>> with the current codebase?
>> Without any critical codechanges I'd go for -1.
>>
>> Robert
>>
>> Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko
>> :
>>
>>> With maven core version change to 3.3.0 on master, any objections I
>>> change compile source/target to java 7?
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Abandoned bugs analysis

[Brian Fox]

+1 close em...

On Tue, Nov 25, 2014 at 4:22 PM, Jason van Zyl  wrote:
> I don't agree. This is a project, not a product and if no one looks at 
> something for 2 years then no one cares. We are not erasing the issues and if 
> someone does care enough to ask to reopen an issue then that's great. But 
> I've tried to purge down the list to something manageable twice now and it 
> keeps growing so I highly appreciate what Michael is doing because it's 
> unmanageable right now. And now that he's done that I have some motivation 
> again to look through the issues so kudos to Michael. Nothing stops anyone 
> from going through and reopening something, I don't think we need group 
> scrubbing sessions. I think core committers need to go through and help 
> curate the issues on a more regular basis.
>
> On Nov 25, 2014, at 4:03 PM, Dennis Lundberg  wrote:
>
>> Hi Michael
>>
>> Unfortunatelly, I think that 2 years of inactivity is way to short time. I
>> wish it wasn't so, but the reality is that the age of an issue is not a
>> good indicator of whether the issue is valid or not.
>>
>> I think a better approach is to have joint bug scrub sessions, where we
>> join forces to manually check the validity of the issues.
>>
>> --
>> Dennis Lundberg
>> Den 24 nov 2014 23:05 skrev "Michael Osipov" :
>>
>>> Hi folks,
>>>
>>> I ran this query in JIRA: project in 
>>> projectsWhereUserHasPermission("Administer
>>> Projects") AND updated <= "2012-12-31" and resolution = Unresolved and type
>>> = Bug ORDER BY created desc
>>>
>>> Bugs which haven't been touched for almost two years. Total amount:
>>> *1139*. A lot of them are still Maven 1.x related 8-).
>>>
>>> Is there someone with bulk change abilities able to close those as "Won't
>>> Fix" with a note like: Big clean up end of 2014, you think that this issue
>>> still persists, reopen it?
>>>
>>> What do you think?
>>>
>>> Michael
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> the course of true love never did run smooth ...
>
>  -- Shakespeare
>
>
>
>
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plexus Archiver / Plexus Components

[Brian Fox]

Herve and I discussed moving the repos before splitting them, but it
made sense to just go ahead and split it first because that was easier
and quicker to pull off. If we can get them into an Apache repo, that
makes sense.

On Tue, Sep 2, 2014 at 3:48 AM, Benson Margulies  wrote:
> Note that we recently split the repos up at Sonatype to make this less
> cumbersome; Brian hands out access pretty much on request. At least,
> he did for _me_.
>
> On Tue, Sep 2, 2014 at 3:09 AM, Kristian Rosenvold
>  wrote:
>> We have started talking about moving them somewhere, and the time may
>> have come tom restart that discussion.
>>
>> You can either ask Brian for access or have one of the existing
>> committers apply your pull request. Just a regular pull request from
>> github should do.
>>
>> Kristian
>>
>>
>> 2014-09-01 22:37 GMT+02:00 Karl Heinz Marbaise :
>>> Hi,
>>>
>>> i just want to know how we handle things which are located in components
>>> like plexus-archiver etc.
>>>
>>> Currently i'm diving into some problems and want to checkin some improvments
>>> on the plexus-archiver...
>>>
>>> How can i gain commit access to those components ?
>>>
>>> Kind regards
>>> Karl-Heinz Marbaise
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Maven 3.2.3 Release

[Brian Fox]

+1

I did a few tests of various cases related to the new url for central
and interactions with repo managers, everything looks ok.

On Mon, Aug 11, 2014 at 5:24 PM, Jason van Zyl  wrote:
> +1
>
> Analyzer...
>
> stagingUrl: https://repository.apache.org/content/repositories/maven-1046
> groupId: org.apache.maven
> artifactId: apache-maven
> version: 3.2.3
>
> Source ZIP url exists.
> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-src.zip
>
> Source ZIP SHA1 url exists.
> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-src.zip.sha1
>
> Binary ZIP url exists.
> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-bin.zip
>
> Binary ZIP SHA1 url exists.
> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-bin.zip.sha1
>
> Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
> 8607b9922d21078133f31ed8523ebae90a871d1f
>
> Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
> 90820a88806beee1a2659c9e10eec6adfa33d818
>
> Git revision of release as determined from 
> maven-core-3.2.3.jar:org/apache/maven/messages/build.properties(buildNumber):
> 33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4
>
> Files that are present in the source distribution but not in the source 
> revision:
> DEPENDENCIES
>
> On Aug 11, 2014, at 2:19 PM, Jason van Zyl  wrote:
>
>> Hi,
>>
>> Time to release Maven 3.2.3!
>>
>> This release contains the important change of switching to HTTPS transport 
>> by default! Please test this release with your builds!
>>
>> Here is a link to Jira with 9 issues resolved:
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20443
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1046/
>>
>> The distributable binaries and sources for testing can be found here:
>> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/
>>
>> Specifically the zip, tarball, and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-bin.zip
>> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-bin.tar.gz
>> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-src.zip
>> https://repository.apache.org/content/repositories/maven-1046/org/apache/maven/apache-maven/3.2.3/apache-maven-3.2.3-src.tar.gz
>>
>> Source release checksum(s):
>> apache-maven-3.2.3-src.zip sha1: 8607b9922d21078133f31ed8523ebae90a871d1f
>>
>> Staging site:
>> http://people.apache.org/~jvanzyl/maven-3.2.3/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Thanks,
>>
>> The Maven Team
>>
>>
>>
>>
>>
>>
>>
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> Three people can keep a secret provided two of them are dead.
>
>  -- Benjamin Franklin
>
>
>
>
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Default to SSL

[Brian Fox]

Pushed

On Mon, Aug 11, 2014 at 2:08 AM, Jason van Zyl  wrote:
> If all the Apache links are working then I think for that change alone it's 
> worth a release.
>
> Brian, if you provide all the links or just make the changes in core I can 
> cut the release quickly.
>
> On Aug 10, 2014, at 6:53 PM, Mark Derricutt  wrote:
>
>> I see that Leiningen has already made a new release defaulting to the SSL 
>> version.
>>
>> I recall from the dev hangout the other week discussion maybe putting it in 
>> behind a setting for 3.2.3 and defaulting it later on? I think I'd be down 
>> for just switching cold turkey.
>>
>> On 11 Aug 2014, at 13:28, Brian Fox wrote:
>>
>>> https://repo.maven.apache.org is up now so we can flip to ssl when
>>> ready. Is the consensus to get this into 3.2.3 or to wait for more
>>> time to test?
>>>
>>> We may want to consider switching the repository.apache.org url in our
>>> poms as well.
>>>
>>> -
>>> 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
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> Three people can keep a secret provided two of them are dead.
>
>  -- Benjamin Franklin
>
>
>
>
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Default to SSL

[Brian Fox]

https://repo.maven.apache.org is up now so we can flip to ssl when
ready. Is the consensus to get this into 3.2.3 or to wait for more
time to test?

We may want to consider switching the repository.apache.org url in our
poms as well.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: plexus components

[Brian Fox]

Hi Herve, this is all set. I didn't split any code but the new repos
are available and added to the plexus team in github.

We should have a discussion on where the proper hosting location for
this really is. If we want to move this to the maven project, I would
support that.

On Fri, Aug 1, 2014 at 6:09 AM, Hervé BOUTEMY  wrote:
> Hi,
>
> While working on Checkstyle, I need to fix concurrency issues on plexus-
> resources, but actual SCM situation doesn't permit it since it's in github but
> not in its own repository.
>
> Then I reworked the overall situation overview of plexus-components [1], since
> this one is not the only one.
>
> If we continue in the direction started for svn to git migration, can some
> Sonatype github manager split plexus-components into 7 parts (plexus-
> components will only be the parent)?
>
> Regards,
>
> Hervé
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus+dependencies
>
>
> -
> 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: Central and Man-in-the-middle

[Brian Fox]

We are already in the process of making this open for free to
everyone. Way back in 2012 the CDN situation was different but we just
renewed the contract and and ssl is part of it. Once this is setup, we
should consider changing the superpom to use ssl by default.

Obviously doing something to validate pgp signatures is even better.

On Mon, Jul 28, 2014 at 10:14 PM, Mark Derricutt  wrote:
> Hey all,
>
> Just been reading [1] after it was mentioned in both #scala and #clojure on
> irc.freenode.org now, is there anything that can be done to alleviate some
> of these issues?
>
> oss.sonatype.org now requires everything to be GPG signed before being
> uploaded to central, but I'm not sure about any of the other means of
> getting artifacts uploaded.
>
> Are there any plugins out there to verify GPG signings of dependencies?
>
> Something to discuss on the dev-hangout maybe?
>
>
> [1] https://news.ycombinator.com/item?id=8099713
>
> -
> 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: Nexus is down?

[Brian Fox]

It went down hard today but I think fortunately I uncovered the issue.
The vm had hundreds of stuck puppet threads that slowly consumed all
the ram until ubuntu started kill -9'ing the pid. The slow death of
swap and ram likely explains a lot of the timeouts recently until
everything finally caved completely. There's a cron job to kill the
zombie puppets so hopefully we don't see that anymore.

On Wed, Jun 18, 2014 at 10:34 AM, Igor Fedorenko  wrote:
> I got 503 page several times during the day and evening yesterday.
>
> --
> Regards,
> Igor
>
>
> On 2014-06-18, 9:13, Jason van Zyl wrote:
>>
>> Two times during the one hour window that I was trying to release that the
>> service was not available. It was an Apache page but I assume Nexus wasn't
>> running behind it or not responding.
>>
>> On Jun 18, 2014, at 8:57 AM, Brian Fox  wrote:
>>
>>> I haven't received any alerts that it's been down although there are
>>> sporadic reports of timeouts. Did you receive a timeout, 502 or
>>> something else?
>>>
>>> Nexus is on shared vm hosts and shared disks and I suspect that some
>>> other guest is occasionally bursting and screwing up the io
>>> throughput.
>>>
>>> On Tue, Jun 17, 2014 at 11:42 AM, Jason van Zyl  wrote:
>>>>
>>>> Can we discuss what kind of hardware Nexus is on? It's gone down again
>>>> while I'm trying to release and it's very annoying.
>>>>
>>>> On Jun 17, 2014, at 9:46 AM, Jason van Zyl  wrote:
>>>>
>>>>> Thanks for bringing it back whoever kicked it.
>>>>>
>>>>> On Jun 17, 2014, at 9:39 AM, Jason van Zyl  wrote:
>>>>>
>>>>>> Is Nexus down for scheduled maintenance or did it just fall over?
>>>>>>
>>>>>> I'm trying to cut the 3.2.2 release and Nexus appears dead:
>>>>>>
>>>>>> https://repository.apache.org
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> --
>>>>>> Jason van Zyl
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> http://twitter.com/takari_io
>>>>>> -
>>>>>>
>>>>>> believe nothing, no matter where you read it,
>>>>>> or who has said it,
>>>>>> not even if i have said it,
>>>>>> unless it agrees with your own reason
>>>>>> and your own common sense.
>>>>>>
>>>>>> -- Buddha
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> --
>>>>> Jason van Zyl
>>>>> Founder,  Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> http://twitter.com/takari_io
>>>>> -
>>>>>
>>>>> You are never dedicated to something you have complete confidence in.
>>>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>>>> They know it is going to rise tomorrow. When people are fanatically
>>>>> dedicated to political or religious faiths or any other kind of
>>>>> dogmas or goals, it's always because these dogmas or
>>>>> goals are in doubt.
>>>>>
>>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> --
>>>> Jason van Zyl
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> -
>>>>
>>>> The modern conservative is engaged in one of man's oldest exercises in
>>>> moral philosophy; that is,
>>>> the search for a superior moral justification for selfishness.
>>>>
>>>> -- John Kenneth Galbraith
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>>
>> Be not afraid of growing slowly, be only afraid of standing still.
>>
>>   -- Chinese Proverb
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> -
> 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: Nexus is down?

[Brian Fox]

https://issues.apache.org/jira/browse/INFRA-7915

On Wed, Jun 18, 2014 at 9:01 AM, Arnaud Héritier  wrote:
> When I noticed it was down on my side it was 503 errors
>
>
> On Wed, Jun 18, 2014 at 2:57 PM, Brian Fox  wrote:
>
>> I haven't received any alerts that it's been down although there are
>> sporadic reports of timeouts. Did you receive a timeout, 502 or
>> something else?
>>
>> Nexus is on shared vm hosts and shared disks and I suspect that some
>> other guest is occasionally bursting and screwing up the io
>> throughput.
>>
>> On Tue, Jun 17, 2014 at 11:42 AM, Jason van Zyl  wrote:
>> > Can we discuss what kind of hardware Nexus is on? It's gone down again
>> while I'm trying to release and it's very annoying.
>> >
>> > On Jun 17, 2014, at 9:46 AM, Jason van Zyl  wrote:
>> >
>> >> Thanks for bringing it back whoever kicked it.
>> >>
>> >> On Jun 17, 2014, at 9:39 AM, Jason van Zyl  wrote:
>> >>
>> >>> Is Nexus down for scheduled maintenance or did it just fall over?
>> >>>
>> >>> I'm trying to cut the 3.2.2 release and Nexus appears dead:
>> >>>
>> >>> https://repository.apache.org
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Jason
>> >>>
>> >>> --
>> >>> Jason van Zyl
>> >>> Founder,  Apache Maven
>> >>> http://twitter.com/jvanzyl
>> >>> http://twitter.com/takari_io
>> >>> -
>> >>>
>> >>> believe nothing, no matter where you read it,
>> >>> or who has said it,
>> >>> not even if i have said it,
>> >>> unless it agrees with your own reason
>> >>> and your own common sense.
>> >>>
>> >>> -- Buddha
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >> Thanks,
>> >>
>> >> Jason
>> >>
>> >> --
>> >> Jason van Zyl
>> >> Founder,  Apache Maven
>> >> http://twitter.com/jvanzyl
>> >> http://twitter.com/takari_io
>> >> -
>> >>
>> >> You are never dedicated to something you have complete confidence in.
>> >> No one is fanatically shouting that the sun is going to rise tomorrow.
>> >> They know it is going to rise tomorrow. When people are fanatically
>> >> dedicated to political or religious faiths or any other kind of
>> >> dogmas or goals, it's always because these dogmas or
>> >> goals are in doubt.
>> >>
>> >>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> > Thanks,
>> >
>> > Jason
>> >
>> > --
>> > Jason van Zyl
>> > Founder,  Apache Maven
>> > http://twitter.com/jvanzyl
>> > http://twitter.com/takari_io
>> > -
>> >
>> > The modern conservative is engaged in one of man's oldest exercises in
>> moral philosophy; that is,
>> > the search for a superior moral justification for selfishness.
>> >
>> >  -- John Kenneth Galbraith
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Nexus is down?

[Brian Fox]

I haven't received any alerts that it's been down although there are
sporadic reports of timeouts. Did you receive a timeout, 502 or
something else?

Nexus is on shared vm hosts and shared disks and I suspect that some
other guest is occasionally bursting and screwing up the io
throughput.

On Tue, Jun 17, 2014 at 11:42 AM, Jason van Zyl  wrote:
> Can we discuss what kind of hardware Nexus is on? It's gone down again while 
> I'm trying to release and it's very annoying.
>
> On Jun 17, 2014, at 9:46 AM, Jason van Zyl  wrote:
>
>> Thanks for bringing it back whoever kicked it.
>>
>> On Jun 17, 2014, at 9:39 AM, Jason van Zyl  wrote:
>>
>>> Is Nexus down for scheduled maintenance or did it just fall over?
>>>
>>> I'm trying to cut the 3.2.2 release and Nexus appears dead:
>>>
>>> https://repository.apache.org
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> --
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> -
>>>
>>> believe nothing, no matter where you read it,
>>> or who has said it,
>>> not even if i have said it,
>>> unless it agrees with your own reason
>>> and your own common sense.
>>>
>>> -- Buddha
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>>
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>>
>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> The modern conservative is engaged in one of man's oldest exercises in moral 
> philosophy; that is,
> the search for a superior moral justification for selfishness.
>
>  -- John Kenneth Galbraith
>
>
>
>
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Brian Fox]

On Fri, Apr 11, 2014 at 5:50 PM, Benson Margulies wrote:

> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly
>  wrote:
> > On 11 April 2014 22:10, Benson Margulies  wrote:
> >
> >> >
> >> > Fwiw, I don't recall the dependency plugin actually injecting stuff
> into
> >> > the project class path but equally wish that the copy/unpack goals
> could
> >> > simply go away regardless. (in leu of the more normal xxx-dependencies
> >> > versions)
> >>
> >> If you make them go away, please find them a new home. I use them
> >> constantly to unpack data resources retrieved from a Maven repo. It
> >> seems odd that they live in a 'dependency' plugin, but it would be a
> >> disaster if they disappeared.
> >>
> >
> > You should be declaring the resources you are unpacking/copying as
> > dependencies and then using the copy-dependencies or unpack-dependencies
> > goal instead of the copy or unpack goal.
>
> I don't want them in the classpath. Even if their filenames end in '.jar'.
>
>
Well, that is the use case I had when I created them originally. I just see
too many people abuse these when they simply could have used the
-dependencies versions just as effectively and with better compatibility to
other plugins.

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Brian Fox]

> My proposal is strictly to prohibit a plugin from modifying a project's
> classpath implicitly. That this become fully explicit such that I can
> remove some of the convoluted logic in the core to account for this.
>
>
Not allowing plugins to randomly inject new dependencies makes sense. I see
some cases where you still want to add a new dependency to the plugin class
path, but from above that sounds unrelated to what you are proposing
changing?

Fwiw, I don't recall the dependency plugin actually injecting stuff into
the project class path but equally wish that the copy/unpack goals could
simply go away regardless. (in leu of the more normal xxx-dependencies
versions)

Re: Model Version 5.0.0

[Brian Fox]

On Sat, Nov 23, 2013 at 11:47 PM, Igor Fedorenko wrote:

> The way I see it, what is deployed describes how the artifact needs to
> be consumed. This is artifact's "public API", if you will, it will be
> consumed by wide range of tools that resolve dependencies from Maven
> repositories and descriptor format should be very stable. Mostly likely
> we have no choice but use (a subset of) the current 4.0.0 model version.
>
> How the artifact is produced, on the other hand, is artifact's
> implementation detail. It is perfectly reasonable for a project to
> require minimal version of Maven, for example. Or use completely
> different format, not related to pom at all.
>
> By separating "consumption" and "production" metadata formats, we'll be
> able to evolve production format more aggressively. For example, it
> would be nice to have Tycho-specific configuration markup inside 
> section. This is not currently possible because all poms must be
> compatible with the same model.
>


+1.

It means we can more easily make changes to the production side, where most
features are desired, without worrying about the impacts on consumption via
older tools. That is to say specifically that a team can decide to move to
a new version of Maven and adjust their pom accordingly without affecting
downstream users. I think this is the very reason we are still locked on
4.0.0 all these years later.

Obviously things like dependency resolution and properties would need to be
in the consumer side.

Re: Submitting a new maven plugin..

[Brian Fox]

Hi Laurent, this does look like an handy plugin. I could actually
imagine these goals being added to the existing clean plugin and also
think this could be pretty popular. What do others think?

On Wed, Aug 7, 2013 at 2:39 AM, labtech.dev  wrote:
> Hi there,
>
> Please first excuse my poor english.. As a simple contributor of a new
> french community, I would like to submit a new maven plugin to the apache
> maven community.
>
> The overall goal of this plugin is to improve the global "local maven
> repository cache" maintenance in an industrial CI context.
>
> For more informations and for a better idea of this plugin basic
> functionnalities, you'll find attached an apache-maven like documentation of
> this plugin.
>
> The source code is temporary available at this URL :
> https://github.com/Finaxys/clean-local-repository-maven-plugin
>
> The original thread regarding to the creation of this plugin can be found
> here : maven local repository cleaner
>
>
> So please, can you answered to my submit request even if it's a negative
> one, in such case, I'll have to change the project groupId to conform with
> an external plugin naming convention..
>
> Independently of my request, lots of thank to your community for having
> produced and shared a such powerfull tool !
>
> Best regards
>
> Laurent Bourhis
>
>
> Mobile (+33)6.34.54.70.05
>
> labtech@gmail.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: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Brian Fox]

Yes, I will take a pass tonight.

On Mon, Aug 5, 2013 at 6:55 AM, Stephen Connolly
 wrote:
> Brian,
>
> Did you have any suggested changes to the forks section wording to clear up
> my intent for that section?
>
> I'd like to start wrapping this up and move towards making it "official"
>
> Everyone else,
>
> Time to shout out if you have any issues / suggested improvements on the
> content
>
> - Stephen
>
> On Friday, 2 August 2013, Stephen Connolly wrote:
>
>> On 2 August 2013 16:07, Brian Fox > 'cvml', 'bri...@infinity.nu');>> wrote:
>>
>>> I think the bulk of this is pretty good. On the fork section,
>>> specifically:
>>>
>>> "
>>> As soon as changes in that
>>> fork are identified which should be brought back to the project those
>>> changes should be introduced into at least a branch hosted on the Apache
>>> Maven
>>> source control in order to facilitate the easier review by the community.
>>>
>>> The PMC should encourage by example the early committing of changes from a
>>> fork back to Apache Maven source control.
>>> "
>>>
>>> This seems to want to compel code to be brought back as a
>>> responsibility, I don't think we need to spell that out.
>>
>>
>> This is why I say "as soon as ... are identified"
>>
>> The wording could be clearer... if somebody can figure out a better way to
>> say it.
>>
>> Basically, as soon as you say something like... "Oh commit 1a2b3d4e, we
>> really need to get that into Maven itself, it's too good to be in our
>> fork"... you should be trying to hasten getting that commit into Maven
>> itself and if you are on the PMC and one of your commits is one that
>> you say this of... you should just commit it back.
>>
>> Until you realise that a commit is one that you want to push to Maven, hey
>> it's your work... whatever... but as soon as you identify the change as
>> being one that should be at Maven, as a PMC member you are expected to try
>> and get it into Maven quickly so that others working on the fork see that
>> this is the example by which the PMC leads.
>>
>> If you can think of a clearer way to express that than my wording (which
>> since you are not getting my intended meaning must therefore be lacking)
>> please update.
>>
>> The section
>>> about the downsides to not doing so and attempting to do it later is
>>> really the core of the concerns... the extra diligence required to
>>> consume large bodies of work is bigger. That doesn't mean that code
>>> contributions are inherently bad just because they were developed
>>> elsewhere, it's just harder to pull in.
>>>
>>
>> Correct.
>>
>>
>>
>> On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
>>  wrote:
>> > I have updated the project-roles with my thoughts resulting from the
>> > healthy debate on the list and some debates elsewhere.
>> >
>> > If anyone wants to look at the resulting Work In Progress document as a
>> > whole:
>> >
>> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup
>> >
>> > Thoughts?
>> >
>> > -Stephen
>> >
>> > -- Forwarded message --
>> > From: 
>> > Date: 2 August 2013 10:52
>> > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
>> > project-roles.md
>> > To: comm...@maven.apache.org
>> >
>> >
>> > Author: stephenc
>> > Date: Fri Aug  2 09:52:11 2013
>> > New Revision: 1509594
>> >
>> > URL: http://svn.apache.org/r1509594
>> > Log:
>> > After a lengthy discussion on the users@maven list and some
>> > side discussions on members@apache, I think the following changes
>> > are more in line with what we should be seeking as responsibilities
>> > of the PMC.
>> >
>> > * Forks are not bad... letting changes stack up in the fork is bad
>> >   but more from a 'it will be hard to review' point of view...
>> >   similarly using a fork to get external contributions complicates
>> >   the tracablity
>> >
>> > * We are not obligated to promote other ASF projects... but there
>> >   should be a symmetry in how that lack of obligation plays out
>> >
>> > * I identified some
>>
>>
>>
>
> --
> Sent from my phone

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Brian Fox]

On Aug 2, 2013, at 12:30 PM, Paul Benedict  wrote:

> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today aren't clear, I'll try again. My stance isn't about
> halting developing elsewhere, but to halt what I (and maybe some others)
> perceive as a way of getting around the Apache community.
>
> I won't use your "ultra whizzbang high performance logging" :-) example
> because it doesn't fit what my concern; but imagine an existing component
> (I won't name any) that is critical and Maven's existence and Maven can't
> function without it. It's very easy for any PMC member to go to another OSS
> community, develop it, and then kind of leave the other PMCs with no real
> "choice" but to use it because the code realizes the future of Maven. Those
> other PMCs are really backed into a corner; they have no real recourse to
> preventing this, lest Maven development is simply halted altogether. The
> other OSS community has other committers, other mailing lists, other
> deliberations, etc. Community work and input becomes marginalized here.
>
> Does this make sense to you? That kind of community-splitting effort needs
> to stop and that's what I am trying to address.


The cat b / core pmc rule was already adopted to address cases like
this. The pmc voted to allow the previous cases so its not like
anything magical happened here. I don't think we need to be overly
broad to spell out every operating rule in the roles and
responsibilities. Keeping tabs on situations like that is exactly the
role of the pmc and I believe the document covers that sufficiently.

>
> Cheers,
> Paul
>
>
>
> On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> We cannot stop somebody from developing something outside of Apache.
>>
>> So I could go off and write a High Performance Logging API... now I could
>> be doing that because I want to foist that Logging API on Maven... or I
>> could be doing it as an experiment that, if successful, I may offer for
>> Maven to consume... or I could be doing it because I need it for my Day
>> Job...
>>
>> We cannot know the reasons why somebody is doing something outside of
>> Maven... we can ask, but we cannot *know* if the answer we are given is
>> truthful.
>>
>> So anyway, I now have this ultra whizzbang high performance logging API and
>> I am aware of some deficit in the logging performance of Maven, so I spin
>> up a private fork (it could be a hidden private fork, or it could be a
>> public one... doesn't matter) and integrate the logging API and low and
>> behold I see a whopping X% improvement... so I want to bring that back to
>> Maven...
>>
>> Is there anything wrong with the above?
>>
>> If the library I created is under a Category A license and open source and
>> I go with CTR and nobody vetos my commit... we have consensus... why do we
>> need to go all Iron Fist and require a vote?
>>
>> We already have established tools: review of commits, vetos on commits,
>> mandatory votes for Category B dependencies...
>>
>> Do we really need *more* processes and procedures to follow?
>>
>> On 2 August 2013 16:51, Paul Benedict  wrote:
>>
>>> I don't understand the iron hand analogy. I was expressing the use of a
>>> vote to allow or disallow critical development outside of Apache. The
>> vote
>>> would lead to a consensus, no?
>>>
>>>
>>> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
 On 2 August 2013 16:32, Paul Benedict  wrote:

> Furthermore, I'd like to see explicit procedural rules on Maven Core
>>> and
> forking. For example, if there's a critical component needing
>>> development
> for Core, and a PMC expresses that such development will be done
>>> outside
 of
> Apache and then used as a dependency, shouldn't there be a vote on
>>> that?

 Votes should be a tool to confirm consensus... not an iron hand.

 If the consensus of the developers is to use the dependency which is
 external to the project, then that is fine. If there is no consensus
>> then
 the dependency will not be introduced.

 We already have a policy that adding Category B dependencies to Core
 requires approval of the PMC, I don't see that there is much value in
 adding even more to this document... but if you can suggest a patch and
 people agree with it...

 -Stephen
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>
>
>
> --
> Cheers,
> Paul

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Brian Fox]

On Fri, Aug 2, 2013 at 12:10 PM, Stephen Connolly
 wrote:
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one... doesn't matter) and integrate the logging API and low and
> behold I see a whopping X% improvement... so I want to bring that back to
> Maven...
>
> Is there anything wrong with the above?


 I say absolutely not. Where things can go wrong is what happens next.
If someone commits that giant chunk with no discussion, then that's
probably going to raise concerns. If instead a discussion is started
to discuss the work and decide if it's appropriate to pull in, then
fine.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Brian Fox]

I think the bulk of this is pretty good. On the fork section, specifically:

"
As soon as changes in that
fork are identified which should be brought back to the project those
changes should be introduced into at least a branch hosted on the Apache Maven
source control in order to facilitate the easier review by the community.

The PMC should encourage by example the early committing of changes from a
fork back to Apache Maven source control.
"

This seems to want to compel code to be brought back as a
responsibility, I don't think we need to spell that out. The section
about the downsides to not doing so and attempting to do it later is
really the core of the concerns... the extra diligence required to
consume large bodies of work is bigger. That doesn't mean that code
contributions are inherently bad just because they were developed
elsewhere, it's just harder to pull in.

On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
 wrote:
> I have updated the project-roles with my thoughts resulting from the
> healthy debate on the list and some debates elsewhere.
>
> If anyone wants to look at the resulting Work In Progress document as a
> whole:
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup
>
> Thoughts?
>
> -Stephen
>
> -- Forwarded message --
> From: 
> Date: 2 August 2013 10:52
> Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
> project-roles.md
> To: comm...@maven.apache.org
>
>
> Author: stephenc
> Date: Fri Aug  2 09:52:11 2013
> New Revision: 1509594
>
> URL: http://svn.apache.org/r1509594
> Log:
> After a lengthy discussion on the users@maven list and some
> side discussions on members@apache, I think the following changes
> are more in line with what we should be seeking as responsibilities
> of the PMC.
>
> * Forks are not bad... letting changes stack up in the fork is bad
>   but more from a 'it will be hard to review' point of view...
>   similarly using a fork to get external contributions complicates
>   the tracablity
>
> * We are not obligated to promote other ASF projects... but there
>   should be a symmetry in how that lack of obligation plays out
>
> * I identified some more responsibilities of the PMC (if I have missed
>   any, please add)
>
> * There is a special case where the PMC Chair can wear the dictators
>   hat... but that is only in the case of unresolvable consensus
>   and the lack of consensus is causing damage to the project
>   and the board is well aware of the issue and expects the chair
>   to put on the dictators hat (with the board watching on)
>
> As always, this is a Commit Then Review community... so these
> changes are being committed for review.
>
> Modified:
> maven/site/trunk/content/markdown/project-roles.md
>
> Modified: maven/site/trunk/content/markdown/project-roles.md
> URL:
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594&r1=1509593&r2=1509594&view=diff
> ==
> --- maven/site/trunk/content/markdown/project-roles.md (original)
> +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug  2 09:52:11
> 2013
> @@ -174,11 +174,31 @@ are kept confidential.
>
>  The Project Management Committee has the following responsibilities:
>
> -* Proposing active contributors for committership,
> -* Binding votes in project decisions,
> -* Voting on release artifacts,
> -* Ensure [Developers Conventions][5] are followed, or updated/improved if
> necessary,
> -* 
> +* Active management of those projects identified by the resolution of the
> Board
> +  of Directors of the Apache Foundation;
> +* Ensure the project remains a healthy top-level project of the Apache
> Foundation
> +  (if a PMC member wants the project to be hosted elsewhere they should
> resign
> +  from the PMC stating their reason - if the PMC shrinks beyond the
> minimal viable
> +  size then as a result of a desire by the bulk of the PMC to move the
> project
> +  elsewhere, the Board of the Apache Foundation will take that into account
> +  when moving the project into the Foundation's Attic)
> +* Prepare reports as required by the Board of the Apache Foundation and
> +  ensure those reports are ready for presentation by the PMC Chair in a
> timely
> +  manner;
> +* Defend the trademarks belonging to the project;
> +* Proposing active contributors for committership;
> +* Ensure that votes in the community are used as a tool to establish
> consensus
> +  and not a weapon to disenfranchise or alienate a minority of the
> community;
> +* Binding votes in project decisions;
> +* Ensure that code committed to the project is either committed under a
> valid CLA
> +  or is code that was contributed with a clear indication that the Apache
> License
> +  applied (i.e. small patches submitted to the issue tracker or to the
> mailing list
> +  are assumed to be submitted with the intent of being 

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

[Brian Fox]

>
> There is at least one Maven Committer who has been maintaining a fork of
> Maven for perhaps the greater part of a year.

Is it really a fork? Or is it a superset? I think people throw around
fork but is that really true?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Older (archiva) binaries not in Central.

[Brian Fox]

Chris, we can add this right to the apache nexus and it will be synced
to Central. No need to do a one-off upload. Do you have a list of the
exact files that are missing?


On Thu, Jul 11, 2013 at 1:57 AM, Chris Graham  wrote:
> ok, cool. I will go and have a look. Thanks!
>
> -Chris
>
>
> On Thu, Jul 11, 2013 at 3:51 PM, Barrie Treloar  wrote:
>
>> On 11 July 2013 14:44, Chris Graham  wrote:
>> > For an existing, actively developed project, yes.
>> >
>> > However, in this case, it's been archived/placed in the attic.
>> >
>> > So the project team does not really exist.
>> >
>> > I can also add bsf V2.4 to the list of missings things as well. :-)
>>
>> If it's OSS and not in Central and the project doesnt upload it (or
>> can't) anyone else Can.
>>
>> There are some links on the page that head off to Sonatype that give
>> more details on what you need to do.
>>
>> But there is no reason why you couldn't be the one to get it installed
>> into Central.
>>
>> -
>> 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: Poposed Sandbox plugins - digest and gpg:signfiles

[Brian Fox]

You mean releases that don't go to the standard release repo? Yes it's
technically possible but it becomes a dangerous thin line between
official release and one that bypasses the usual asf process.

--mobile

On Jun 22, 2013, at 8:07 PM, sebb  wrote:

> On 23 June 2013 01:00, Olivier Lamy  wrote:
>> 2013/6/23 sebb :
>>> Also, is there a Sandbox repo where the plugins can be deployed for testing?
>>> Or is it up to users to checkout the source and install the plugins locally?
>>
>> We can deploy snapshots to repository.a.o
>
> OK but what about non-snapshot versions?
> Obviously they cannot be published to the Maven Central repo, but is
> there a local repo like Codehaus have?
>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>>
>> --
>> Olivier Lamy
>> Ecetera: http://ecetera.com.au
>> 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
>
> -
> 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: [VOTE] Apache 3.1.0-alpha-1 (Take 4)

[Brian Fox]

+1

On Sat, Jun 1, 2013 at 9:13 AM, Jason van Zyl  wrote:
> Here are the release bits for 3.1.0-alpha-1:
>
> Release notes:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-046/
>
> Staged distribution:
> https://repository.apache.org/content/repositories/maven-046/org/apache/maven/apache-maven/3.1.0-alpha-1/
>
> Staged Site:
> http://maven.apache.org/ref/3.1.0-alpha-1
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Dependency Tree version 2.1

[Brian Fox]

Yes that should do it.

On Fri, May 3, 2013 at 3:20 AM, Mirko Friedenhagen
 wrote:
> Hello Hervé,
>
> as an enduser, I just define this as a dependency to  e.g. the
> maven-dependency-plugin, right?
>
> Regards Mirko
> --
> Sent from my mobile
> On May 3, 2013 2:04 AM, "Hervé BOUTEMY"  wrote:
>
>> Hi,
>>
>> We solved 2 issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=18714&styleName=Html
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-164/
>>
>> https://repository.apache.org/content/repositories/maven-164/org/apache/maven/shared/maven-dependency-tree/2.1/maven-dependency-tree-2.1-source-release.zip
>>
>> Staging site (svnpubsub in progress):
>> http://maven.apache.org/shared-archives/maven-dependency-tree-2.1/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> -
>> 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: [Vote #2] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Brian Fox]

+1


On Mon, Mar 11, 2013 at 1:04 PM, Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> +1 to release.
>
> Thanks,
> Henning
>
>
>
>
> On Mon, Mar 11, 2013 at 9:44 AM, John Casey 
> wrote:
>
> > Bump...
> >
> > Has this vote failed, then, or are we saying that all the +1's from the
> > previous round of voting should be counted here? There is new code in
> this
> > vote, so I'm not 100% sure that's a good idea.
> >
> > I can complete the release of the dependency analyzer, I guess, as that
> > code has not changed.
> >
> > On 3/7/13 1:48 PM, John Casey wrote:
> >
> >> Hi,
> >>
> >> This vote is for the Maven dependency plugin version 2.7, which also
> >> requires the release of Maven shared dependency analyzer version 1.4.
> >>
> >> The first vote failed due to MDEP-391. Since I had previously staged
> >> both of these together, I had to redeploy the same tag for the
> >> maven-dependency-analyzer to a new staging repo, then deploy the new
> >> code for the maven-dependency-plugin to another staging repo. The new
> >> repos are listed below.
> >>
> >> maven-dependency-plugin 2.7:
> >> 
> >>
> >> We solved 7 issues: http://s.apache.org/cmZc
> >>
> >> The new issue from the first vote is MDEP-391.
> >>
> >> There are still issues left in JIRA: http://s.apache.org/N6u
> >>
> >>
> >> maven-dependency-analyzer 1.4:
> >> --
> >>
> >> We solved 1 issue: http://s.apache.org/48k
> >>
> >> There is still 1 issue left in JIRA: http://s.apache.org/ZCc
> >>
> >> ---
> >>
> >> Staging repos:
> >>
> >> https://repository.apache.org/**content/repositories/maven-**339/<
> https://repository.apache.org/content/repositories/maven-339/>
> >> https://repository.apache.org/**content/repositories/maven-**340/<
> https://repository.apache.org/content/repositories/maven-340/>
> >>
> >> * maven-dependency-analyzer is under maven-339
> >> * maven-dependency-plugin is under maven-340
> >>
> >>
> >> Source releases:
> >>
> >> http://s.apache.org/mda-1.4-**src.zip<
> http://s.apache.org/mda-1.4-src.zip> (maven-dependency-analyzer 1.4)
> >> http://s.apache.org/mdep-2.7-**src.zip<
> http://s.apache.org/mdep-2.7-src.zip>(maven-dependency-plugin 2.7)
> >>
> >>
> >> Staging site:
> >>
> >> http://maven.apache.org/**shared-archives/maven-**
> >> dependency-analyzer-1.4/<
> http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/>
> >>
> http://maven.apache.org/**plugins-archives/maven-**dependency-plugin-2.7/<
> http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/>
> >>
> >> Guide to testing staged releases:
> >>
> >> http://maven.apache.org/**guides/development/guide-**
> >> testing-releases.html<
> http://maven.apache.org/guides/development/guide-testing-releases.html>
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >>
> >> Here's my +1.
> >>
> >> -john
> >>
> >>
> >
> > --
> > John Casey
> > Developer, PMC Member - Apache Maven (http://maven.apache.org)
> > GitHub - http://github.com/jdcasey
> >
> > --**--**-
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
> dev-unsubscr...@maven.apache.org>
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: The next major release of Maven: 4.0.0

[Brian Fox]

I don't think we should move to 4.0 because of this. The primary consumer
of our systems are the end users and this change doesn't represent "api"
breakage to them. If we make what appears to be such a large version
change, that could scare off or confuse people who are just now warming up
to 3.x. I think this does need to be resolved, but lets just call it 3.1
and notify the plugins that need to know directly.


On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl  wrote:

>
> On Mar 6, 2013, at 6:09 PM, Olivier Lamy  wrote:
>
> > 2013/3/4 Hervé BOUTEMY :
> >> some more personal thoughts and questions to make myself an opinion
> >>
> >> - about determining whether Aether API is biased or not: there was an
> argument
> >> for not developing Aether in Maven that was "Aether API will be more
> generic
> >> to cover other dependency resolution mecanisms and repository formats,
> like
> >> P2". Is there something done on this area (be it P2 or anyhting else
> outside
> >> Maven use)?
> >>
> >> - about maintaining a 3.1.0 bugfix branch like the actual one in
> parallel with
> >> the master incorporating Eclipse Aether: isn't it the area where the
> git move
> >> was expected to help? The 3.1.0 is just a bugfix branch, without much
> commits
> >> expected since the work will happen on master (and on every
> components/plugins
> >> having an impact from Eclipse Aether integration), or do I miss
> something?
> >> I suppose these outside component will require some time to adapt and
> propose
> >> a solution for users.
> >
> > In such case why not using the opportunity of 4.0.0 to back to a
> > org.apache.maven namespace (with a wrapper on top of the real
> > implementation).
>
> Go for it. As I wrote previously if anyone wants to make a shim or
> compatibility layer over Eclipse Aether they are welcome too. I'm not doing
> for all the reasons I cited previously, but feel free to take the
> opportunity.
>
> > At least that will be a more stable namespace. (If did as it since the
> > beginning we could think about something else now !)
> >
> >>
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit :
> >>> Stephen,
> >>>
> >>> It doesn't matter where the code is. It's complicated, takes a lot of
> effort
> >>> to understand and I don't really care, or see it as a problem that
> Benjamin
> >>> is the one who works on it most. No one else worked on here, no one
> else is
> >>> working on it there. It's not where it is, it's that it's a non-trivial
> >>> body of code that requires focus and effort that any casual observer
> >>> doesn't have the time for. The only people who have ever worked on it
> are
> >>> those that were employed to work on it specifically. I don't see this
> as an
> >>> issue, it's simply the way it is.
> >>>
> >>> Aether is already exposed and it's because the Maven Artifact APIs are
> >>> anemic that it's used directly. Aether is complete, anything else made
> is
> >>> just going to make a huge wrapper around that which serves no purpose
> >>> really. If in the 18 months since Aether has been at Eclipse nothing
> has
> >>> been done do you really think anything can be made in a timely
> fashion? I
> >>> think that unlikely. There's probably 1000 man hours in Aether at
> least and
> >>> there's probably lots of biases in the codebase because no one
> contributes
> >>> anything to it for all the reasons cited above. Such is the reality we
> have
> >>> right now.
> >>>
> >>> Until I actually merged in Eclipse Aether, worked with Benjamin to get
> all
> >>> the ITs working, and testing it in the field with 10 or so people I
> didn't
> >>> know how much work was involved, or what plugins were affected until I
> >>> started getting feedback. I am not interested in weaving stuff back and
> >>> forth between the branches given that all the ITs work with Eclipse
> Aether
> >>> merged in and there are a few plugin compatibility issues.
> >>>
> >>> I myself cannot imagine trying to keep the two of those branches in
> sync and
> >>> I don't see the point because the Eclipse Aether stuff is ready. I
> have the
> >>> energy to maintain what I proposed. Even if someone wanted to stand up
> and
> >>> maintain the 3.1.x branch I believe it would be a waste of time given
> what
> >>> little time the core receives.
> >>> On Mar 3, 2013, at 5:54 PM, Stephen Connolly
> >>  wrote:
>  On 3 March 2013 14:16, Jason van Zyl  wrote:
> > Hi,
> >
> > No one seems to object to doing a release with the SLF4J support
> without
> > the isolation so I wanted to discuss what happens when we integrate
> > Eclipse
> > Aether and suggest an alternate release path.
> >
> > SLF4J may cause some issues, but the introduction of Eclipse Aether
> is
> > almost certainly going to cause issues. In Eclipse Aether some
> internal
> > representations have been changed and it's not completely backward
> > compatible. These changes have been made for good reason

Re: [Vote] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Brian Fox]

For some reason, Dain's reply spawned a new thread, content below for
archives:

On Wed, Mar 6, 2013 at 2:48 PM, Dain Sundstrom  wrote:

> -1 The unpack goal has a new property "ignorePermissions" with a default
> value of "true".  The 2.6 version of the plugin did not have this property
> and did set permissions, so the new default is a backwards incompatible
> change.  Also this new property is not documented in the release notes:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18926&styleName=Text&projectId=11214
>
> -dain



On Thu, Mar 7, 2013 at 11:30 AM, Brian Fox  wrote:

> The commit I made for MDEP-391 fixes the issue, I think we just need to
> drop and restage the plugin (the analyzer component is fine)
>
>
> On Thu, Mar 7, 2013 at 9:28 AM, John Casey  wrote:
>
>> Sorry, I missed the reference. Where is dain's problem detailed? It seems
>> like the thread discussion following this message was related to a
>> different issue, unless I'm missing something in the issue details...
>>
>> What do we need to do to move forward with another vote?
>>
>>
>> On 3/6/13 3:22 PM, Brian Fox wrote:
>>
>>> -1 based on dain's discovery on permissions.
>>>
>>>
>>> On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy  wrote:
>>>
>>>  +1
>>>>
>>>> 2013/3/5 John Casey :
>>>>
>>>>> Hi,
>>>>>
>>>>> This vote is for the Maven dependency plugin version 2.7, which also
>>>>> requires the release of Maven shared dependency analyzer version 1.4.
>>>>>
>>>>> maven-dependency-plugin 2.7:
>>>>> 
>>>>>
>>>>> We solved 6 issues: http://s.apache.org/cmZc
>>>>>
>>>>> There are still issues left in JIRA: http://s.apache.org/N6u
>>>>>
>>>>>
>>>>> maven-dependency-analyzer 1.4:
>>>>> --
>>>>>
>>>>> We solved 1 issue: http://s.apache.org/48k
>>>>>
>>>>> There is still 1 issue left in JIRA: http://s.apache.org/ZCc
>>>>>
>>>>> ---
>>>>>
>>>>> Staging repo:
>>>>>
>>>>> https://repository.apache.org/**content/repositories/maven-**332/<https://repository.apache.org/content/repositories/maven-332/>
>>>>>
>>>>>
>>>>> Source releases:
>>>>>
>>>>> http://s.apache.org/xP  (maven-dependency-analyzer 1.4)
>>>>> http://s.apache.org/PkY (maven-dependency-plugin 2.7)
>>>>>
>>>>>
>>>>> Staging site:
>>>>>
>>>>> http://maven.apache.org/**shared-archives/maven-**
>>>>> dependency-analyzer-1.4/<http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/>
>>>>> http://maven.apache.org/**plugins-archives/maven-**
>>>>> dependency-plugin-2.7/<http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/>
>>>>>
>>>>> Guide to testing staged releases:
>>>>>
>>>>> http://maven.apache.org/**guides/development/guide-**
>>>>> testing-releases.html<http://maven.apache.org/guides/development/guide-testing-releases.html>
>>>>>
>>>>> Vote open for 72 hours.
>>>>>
>>>>> [ ] +1
>>>>> [ ] +0
>>>>> [ ] -1
>>>>>
>>>>>
>>>>> Here's my +1.
>>>>>
>>>>> -john
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>>> GitHub - http://github.com/jdcasey
>>>>>
>>>>> --**--**
>>>>> -
>>>>> To unsubscribe, e-mail: 
>>>>> dev-unsubscribe@maven.apache.**org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>> --**--**
>>>> -
>>>> To unsubscribe, e-mail: 
>>>> dev-unsubscribe@maven.apache.**org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> GitHub - http://github.com/jdcasey
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@maven.apache.**org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: [Vote] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Brian Fox]

The commit I made for MDEP-391 fixes the issue, I think we just need to
drop and restage the plugin (the analyzer component is fine)


On Thu, Mar 7, 2013 at 9:28 AM, John Casey  wrote:

> Sorry, I missed the reference. Where is dain's problem detailed? It seems
> like the thread discussion following this message was related to a
> different issue, unless I'm missing something in the issue details...
>
> What do we need to do to move forward with another vote?
>
>
> On 3/6/13 3:22 PM, Brian Fox wrote:
>
>> -1 based on dain's discovery on permissions.
>>
>>
>> On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy  wrote:
>>
>>  +1
>>>
>>> 2013/3/5 John Casey :
>>>
>>>> Hi,
>>>>
>>>> This vote is for the Maven dependency plugin version 2.7, which also
>>>> requires the release of Maven shared dependency analyzer version 1.4.
>>>>
>>>> maven-dependency-plugin 2.7:
>>>> 
>>>>
>>>> We solved 6 issues: http://s.apache.org/cmZc
>>>>
>>>> There are still issues left in JIRA: http://s.apache.org/N6u
>>>>
>>>>
>>>> maven-dependency-analyzer 1.4:
>>>> --
>>>>
>>>> We solved 1 issue: http://s.apache.org/48k
>>>>
>>>> There is still 1 issue left in JIRA: http://s.apache.org/ZCc
>>>>
>>>> ---
>>>>
>>>> Staging repo:
>>>>
>>>> https://repository.apache.org/**content/repositories/maven-**332/<https://repository.apache.org/content/repositories/maven-332/>
>>>>
>>>>
>>>> Source releases:
>>>>
>>>> http://s.apache.org/xP  (maven-dependency-analyzer 1.4)
>>>> http://s.apache.org/PkY (maven-dependency-plugin 2.7)
>>>>
>>>>
>>>> Staging site:
>>>>
>>>> http://maven.apache.org/**shared-archives/maven-**
>>>> dependency-analyzer-1.4/<http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/>
>>>> http://maven.apache.org/**plugins-archives/maven-**
>>>> dependency-plugin-2.7/<http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/>
>>>>
>>>> Guide to testing staged releases:
>>>>
>>>> http://maven.apache.org/**guides/development/guide-**
>>>> testing-releases.html<http://maven.apache.org/guides/development/guide-testing-releases.html>
>>>>
>>>> Vote open for 72 hours.
>>>>
>>>> [ ] +1
>>>> [ ] +0
>>>> [ ] -1
>>>>
>>>>
>>>> Here's my +1.
>>>>
>>>> -john
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>> GitHub - http://github.com/jdcasey
>>>>
>>>> --**--**
>>>> -
>>>> To unsubscribe, e-mail: 
>>>> dev-unsubscribe@maven.apache.**org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> dev-unsubscribe@maven.apache.**org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>>
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [Vote] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Brian Fox]

I don't know for sure this field fixed the original issue. If it does,
the go ahead and close it

--mobile

On Mar 6, 2013, at 5:37 PM, Olivier Lamy  wrote:

> 2013/3/6 Brian Fox :
>> MDEP-391 introduced this problem, just committed a fix for it.
> why not closing the issue ? Saying a fastest option exists but off per default
>>
>>
>> On Wed, Mar 6, 2013 at 4:22 PM, Brian Fox  wrote:
>>
>>> -1 based on dain's discovery on permissions.
>>>
>>>
>>> On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy  wrote:
>>>
>>>> +1
>>>>
>>>> 2013/3/5 John Casey :
>>>>> Hi,
>>>>>
>>>>> This vote is for the Maven dependency plugin version 2.7, which also
>>>>> requires the release of Maven shared dependency analyzer version 1.4.
>>>>>
>>>>> maven-dependency-plugin 2.7:
>>>>> 
>>>>>
>>>>> We solved 6 issues: http://s.apache.org/cmZc
>>>>>
>>>>> There are still issues left in JIRA: http://s.apache.org/N6u
>>>>>
>>>>>
>>>>> maven-dependency-analyzer 1.4:
>>>>> --
>>>>>
>>>>> We solved 1 issue: http://s.apache.org/48k
>>>>>
>>>>> There is still 1 issue left in JIRA: http://s.apache.org/ZCc
>>>>>
>>>>> ---
>>>>>
>>>>> Staging repo:
>>>>>
>>>>> https://repository.apache.org/content/repositories/maven-332/
>>>>>
>>>>>
>>>>> Source releases:
>>>>>
>>>>> http://s.apache.org/xP  (maven-dependency-analyzer 1.4)
>>>>> http://s.apache.org/PkY (maven-dependency-plugin 2.7)
>>>>>
>>>>>
>>>>> Staging site:
>>>>>
>>>>> http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/
>>>>> http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/
>>>>>
>>>>> Guide to testing staged releases:
>>>>>
>>>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>>>
>>>>> Vote open for 72 hours.
>>>>>
>>>>> [ ] +1
>>>>> [ ] +0
>>>>> [ ] -1
>>>>>
>>>>>
>>>>> Here's my +1.
>>>>>
>>>>> -john
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>>> GitHub - http://github.com/jdcasey
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>
>
>
> --
> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [Vote] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Brian Fox]

MDEP-391 introduced this problem, just committed a fix for it.


On Wed, Mar 6, 2013 at 4:22 PM, Brian Fox  wrote:

> -1 based on dain's discovery on permissions.
>
>
> On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy  wrote:
>
>> +1
>>
>> 2013/3/5 John Casey :
>> > Hi,
>> >
>> > This vote is for the Maven dependency plugin version 2.7, which also
>> > requires the release of Maven shared dependency analyzer version 1.4.
>> >
>> > maven-dependency-plugin 2.7:
>> > 
>> >
>> > We solved 6 issues: http://s.apache.org/cmZc
>> >
>> > There are still issues left in JIRA: http://s.apache.org/N6u
>> >
>> >
>> > maven-dependency-analyzer 1.4:
>> > --
>> >
>> > We solved 1 issue: http://s.apache.org/48k
>> >
>> > There is still 1 issue left in JIRA: http://s.apache.org/ZCc
>> >
>> > ---
>> >
>> > Staging repo:
>> >
>> > https://repository.apache.org/content/repositories/maven-332/
>> >
>> >
>> > Source releases:
>> >
>> > http://s.apache.org/xP  (maven-dependency-analyzer 1.4)
>> > http://s.apache.org/PkY (maven-dependency-plugin 2.7)
>> >
>> >
>> > Staging site:
>> >
>> > http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/
>> > http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/
>> >
>> > Guide to testing staged releases:
>> >
>> > http://maven.apache.org/guides/development/guide-testing-releases.html
>> >
>> > Vote open for 72 hours.
>> >
>> > [ ] +1
>> > [ ] +0
>> > [ ] -1
>> >
>> >
>> > Here's my +1.
>> >
>> > -john
>> >
>> > --
>> > John Casey
>> > Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> > GitHub - http://github.com/jdcasey
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>>
>>
>>
>> --
>> 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: [Vote] maven-dependency-plugin 2.7 AND maven-dependency-analyzer 1.4

[Brian Fox]

-1 based on dain's discovery on permissions.


On Wed, Mar 6, 2013 at 10:15 AM, Olivier Lamy  wrote:

> +1
>
> 2013/3/5 John Casey :
> > Hi,
> >
> > This vote is for the Maven dependency plugin version 2.7, which also
> > requires the release of Maven shared dependency analyzer version 1.4.
> >
> > maven-dependency-plugin 2.7:
> > 
> >
> > We solved 6 issues: http://s.apache.org/cmZc
> >
> > There are still issues left in JIRA: http://s.apache.org/N6u
> >
> >
> > maven-dependency-analyzer 1.4:
> > --
> >
> > We solved 1 issue: http://s.apache.org/48k
> >
> > There is still 1 issue left in JIRA: http://s.apache.org/ZCc
> >
> > ---
> >
> > Staging repo:
> >
> > https://repository.apache.org/content/repositories/maven-332/
> >
> >
> > Source releases:
> >
> > http://s.apache.org/xP  (maven-dependency-analyzer 1.4)
> > http://s.apache.org/PkY (maven-dependency-plugin 2.7)
> >
> >
> > Staging site:
> >
> > http://maven.apache.org/shared-archives/maven-dependency-analyzer-1.4/
> > http://maven.apache.org/plugins-archives/maven-dependency-plugin-2.7/
> >
> > Guide to testing staged releases:
> >
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Here's my +1.
> >
> > -john
> >
> > --
> > John Casey
> > Developer, PMC Member - Apache Maven (http://maven.apache.org)
> > GitHub - http://github.com/jdcasey
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
>
> --
> 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: [VOTE] formally end support for Maven 1

[Brian Fox]

+1


On Sun, Mar 3, 2013 at 5:34 AM, Hervé BOUTEMY  wrote:

> +1
>
> Regards,
>
> Hervé
>
> Le samedi 2 mars 2013 07:18:51 Benson Margulies a écrit :
> > Based on the sentiment on the discussion thread, I call a formal vote
> > to end support for Maven 1.x. This is a vote to:
> >
> > 1: Remove maven 1 release materials from the primary distribution
> > area, leaving them only on the archive.
> >
> > 2: Make appropriate changes to the web site to state clearly that the
> > community no longer provides support for Maven 1.
> >
> > This vote will be open for until Wed March 6, 00:00 GMT (we're not in
> > a hurry here).
> >
> > Here is my +1.
> >
> > -
> > 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: Desupport Maven 1

[Brian Fox]

On Wed, Feb 27, 2013 at 10:56 AM, Benson Margulies wrote:

> If someone else
> wants to support it, they are welcome to do so elsewhere.
>

Or here through active participation. But while we don't have active
committers supporting it, we should say so. Nothing stops us from doing
more than the official policy, or from changing it in the future. We should
at least be explicit to the users about what to expect.

Re: Desupport Maven 1

[Brian Fox]

+1 and take if off the dist site.


On Wed, Feb 27, 2013 at 10:42 AM, Benson Margulies wrote:

> Are there any readers on this list who are prepared to respond to any
> issues on Maven 1.x, especially, for example, security issues? Does
> anyone know how to make a release? Unless that set is non-empty, we
> really need to 'retire' it, I claim.
>
> On Wed, Feb 27, 2013 at 10:37 AM, Anders Hammar  wrote:
> > Yes, this line is not really true:
> > "Note that *no further development* is planned for the Maven-1.0 branch,
> > and Maven-1.1 is in maintenance mode, i.e. development is restricted to
> > support and bug fixes."
> >
> > /Anders
> >
> >
> > On Wed, Feb 27, 2013 at 7:33 PM, Benson Margulies  >wrote:
> >
> >> I think it's long overtime for us to officially disclaim support for
> Maven
> >> 1.
> >>
> >> -
> >> 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: [ANN] Apache Maven 3.0.5 released

[Brian Fox]

Just wanted to bring this to the users list and ensure that those reading
the release notes see the security alert for 3.0.4:

CVE-2013-0253 Apache Maven

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:
- Apache Maven 3.0.4
- Apache Maven Wagon 2.1, 2.2, 2.3

 Description:
Apache Maven 3.0.4 (with Apache Maven Wagon 2.1) has introduced a non-secure
SSL mode by default. This mode disables all SSL certificate checking,
including: host name verification , date validity,  and certificate
chain. Not validating the certificate introduces the possibility of a
man-in-the-middle attack.

All users are recommended to upgrade to Apache Maven 3.0.5 and Apache
Maven Wagon 2.4.

 Credit
This issue was identified by Graham Leggett

--
The Apache Maven Team


On Sat, Feb 23, 2013 at 9:58 AM, Olivier Lamy  wrote:

> Hello,
>
> The Apache Maven team is pleased to announce the release of Apache Maven
> 3.0.5
>
> Release notes available:
> http://maven.apache.org/docs/3.0.5/release-notes.html .
>
> Maven is a project comprehension and build tool, designed to simplify
> the process of maintaining a healthy development lifecycle for your
> project.
>
> You can read more here:
>
> http://maven.apache.org/
>
> Downloads of source and binary distributions are listed in our
> download  section:
>
> http://maven.apache.org/download.html
>
> A major goal of Maven 3.0.x is to be compatible, to the extent
> possible, with existing plugins and projects designed for Maven 2.x.
> Users interested in upgrading to 3.x should have a glance at the
> compatibility notes for known differences between Maven 3.0 and Maven
> 2.x:
>
> http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html
>
> Users who already use Maven 3.0.x are encouraged to update to this new
> maintenance release.
>
> If you encounter unexpected problems while using Apache Maven 3.0.5,
> please feel free to contact us via the Maven developer list:
>
> http://maven.apache.org/mail-lists.html
>
> Release Notes - Apache Maven 2 & 3 - Version 3.0.5
>
> ** Bug
>   * [MNG-5430] - use wagon 2.4
>
>
> Have Fun!
>
> -- The Apache Maven Team.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: git commit: fixed typo

[Brian Fox]

+1


On Tue, Feb 5, 2013 at 1:26 PM, Robert Scholte  wrote:

> Hi,
>
> I have my doubts if this should be exposed as a mvn argument. This would
> also mean that we cannot remove it in the future. It would also suggest
> that it is a valid solution, but in fact it makes your build more
> unreliable.
> Users hitting this issue have often enough Maven knowledge to discover
> this option, so I don't see the need for this mvn commandline argument.
> Instead I would only use the MAVEN_OPTS option, and rename it to
> LegacyLocalRepository instead of SimpleLocalRepository to encourage not to
> use it.
>
> WDYT?
>
> Robert
>
>
> Op Tue, 05 Feb 2013 00:02:47 +0100 schreef Hervé BOUTEMY <
> herve.bout...@free.fr>:
>
>
>  good idea
>>
>> any objection?
>>
>> Regards,
>>
>> Hervé
>>
>> Le lundi 4 février 2013 11:11:32 Brian Fox a écrit :
>>
>>> i'm on the fence about if this is good or not, but I think the option if
>>> provided should be simple-local-repository without the manager part.
>>> People
>>> already get confused about what's a local repo vs what's a repository
>>> manager and the mixing of these concepts here will make that worse.
>>>
>>> On Sat, Feb 2, 2013 at 10:59 AM,  wrote:
>>> > Updated Branches:
>>> >   refs/heads/master 71dd7f3d2 -> 5d06bc6a2
>>> >
>>> > fixed typo
>>> >
>>> > Project: 
>>> > http://git-wip-us.apache.org/**repos/asf/maven/repo<http://git-wip-us.apache.org/repos/asf/maven/repo>
>>> > Commit: http://git-wip-us.apache.org/**repos/asf/maven/commit/**
>>> 5d06bc6a <http://git-wip-us.apache.org/repos/asf/maven/commit/5d06bc6a>
>>> > Tree: 
>>> > http://git-wip-us.apache.org/**repos/asf/maven/tree/5d06bc6a<http://git-wip-us.apache.org/repos/asf/maven/tree/5d06bc6a>
>>> > Diff: 
>>> > http://git-wip-us.apache.org/**repos/asf/maven/diff/5d06bc6a<http://git-wip-us.apache.org/repos/asf/maven/diff/5d06bc6a>
>>> >
>>> > Branch: refs/heads/master
>>> > Commit: 5d06bc6a25d40da49b9f477e3c2b40**8505dbae61
>>> > Parents: 71dd7f3
>>> > Author: Hervé Boutemy 
>>> > Authored: Sat Feb 2 16:59:20 2013 +0100
>>> > Committer: Hervé Boutemy 
>>> > Committed: Sat Feb 2 16:59:20 2013 +0100
>>> >
>>> > --**--**
>>> --
>>> >
>>> >  .../main/java/org/apache/**maven/DefaultMaven.java   |2 +-
>>> >  .../execution/**DefaultMavenExecutionRequest.**java|   10
>>> +-
>>> >  .../maven/execution/**MavenExecutionRequest.java |4 ++--
>>> >  .../main/java/org/apache/**maven/cli/CLIManager.java |4 ++--
>>> >  .../main/java/org/apache/**maven/cli/MavenCli.java   |2 +-
>>> >  5 files changed, 11 insertions(+), 11 deletions(-)
>>> >
>>> > --**--**
>>> --
>>> >
>>> >
>>> >
>>> > http://git-wip-us.apache.org/**repos/asf/maven/blob/5d06bc6a/**
>>> maven-core/src/<http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/>
>>> > main/java/org/apache/maven/**DefaultMaven.java
>>> > --**--**
>>> --
>>> > diff --git a/maven-core/src/main/java/**org/apache/maven/DefaultMaven.
>>> **java
>>> > b/maven-core/src/main/java/**org/apache/maven/DefaultMaven.**java
>>> > index d85f1ac..ac92afc 100644
>>> > --- a/maven-core/src/main/java/**org/apache/maven/DefaultMaven.**java
>>> > +++ b/maven-core/src/main/java/**org/apache/maven/DefaultMaven.**java
>>> > @@ -358,7 +358,7 @@ public class DefaultMaven
>>> >
>>> >  LocalRepository localRepo = new LocalRepository(
>>> >
>>> > request.getLocalRepository().**getBasedir() );
>>> >
>>> > -if ( request.**isUseSimpleLocalRepostoryManag**er() )
>>> > +if ( request.**isUseSimpleLocalRepositoryMana**ger() )
>>> >
>>> >  {
>>> >
>>> >  try
>>> >  {
>>> >
>>> > http://git-wip-us.apache.org/**repos/asf/maven/blob/5d06bc6a/**
>>> maven-core/src/<http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/>
>>

Re: git commit: fixed typo

[Brian Fox]

i'm on the fence about if this is good or not, but I think the option if
provided should be simple-local-repository without the manager part. People
already get confused about what's a local repo vs what's a repository
manager and the mixing of these concepts here will make that worse.


On Sat, Feb 2, 2013 at 10:59 AM,  wrote:

> Updated Branches:
>   refs/heads/master 71dd7f3d2 -> 5d06bc6a2
>
>
> fixed typo
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/5d06bc6a
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/5d06bc6a
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/5d06bc6a
>
> Branch: refs/heads/master
> Commit: 5d06bc6a25d40da49b9f477e3c2b408505dbae61
> Parents: 71dd7f3
> Author: Hervé Boutemy 
> Authored: Sat Feb 2 16:59:20 2013 +0100
> Committer: Hervé Boutemy 
> Committed: Sat Feb 2 16:59:20 2013 +0100
>
> --
>  .../main/java/org/apache/maven/DefaultMaven.java   |2 +-
>  .../execution/DefaultMavenExecutionRequest.java|   10 +-
>  .../maven/execution/MavenExecutionRequest.java |4 ++--
>  .../main/java/org/apache/maven/cli/CLIManager.java |4 ++--
>  .../main/java/org/apache/maven/cli/MavenCli.java   |2 +-
>  5 files changed, 11 insertions(+), 11 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
> --
> diff --git a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
> b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
> index d85f1ac..ac92afc 100644
> --- a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
> +++ b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
> @@ -358,7 +358,7 @@ public class DefaultMaven
>
>  LocalRepository localRepo = new LocalRepository(
> request.getLocalRepository().getBasedir() );
>
> -if ( request.isUseSimpleLocalRepostoryManager() )
> +if ( request.isUseSimpleLocalRepositoryManager() )
>  {
>  try
>  {
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
> --
> diff --git
> a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
> b/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
> index 3139846..09ead1a 100644
> ---
> a/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
> +++
> b/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java
> @@ -143,7 +143,7 @@ public class DefaultMavenExecutionRequest
>   */
>  private boolean noSnapshotUpdates;
>
> -private boolean useSimpleLocalRepostoryManager = false;
> +private boolean useSimpleLocalRepositoryManager = false;
>
>  public DefaultMavenExecutionRequest()
>  {
> @@ -1078,14 +1078,14 @@ public class DefaultMavenExecutionRequest
>  return this;
>  }
>
> -public boolean isUseSimpleLocalRepostoryManager()
> +public boolean isUseSimpleLocalRepositoryManager()
>  {
> -return this.useSimpleLocalRepostoryManager;
> +return this.useSimpleLocalRepositoryManager;
>  }
>
> -public MavenExecutionRequest setUseSimpleLocalRepostoryManager(
> boolean useSimpleLocalRepostoryManager )
> +public MavenExecutionRequest setUseSimpleLocalRepositoryManager(
> boolean useSimpleLocalRepositoryManager )
>  {
> -this.useSimpleLocalRepostoryManager =
> useSimpleLocalRepostoryManager;
> +this.useSimpleLocalRepositoryManager =
> useSimpleLocalRepositoryManager;
>  return this;
>  }
>  }
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/5d06bc6a/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java
> --
> diff --git
> a/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java
> b/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java
> index 5bd839a..cb4b207 100644
> ---
> a/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java
> +++
> b/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java
> @@ -286,11 +286,11 @@ public interface MavenExecutionRequest
>  /**
>   * @since 3.1
>   */
> -boolean isUseSimpleLocalRepostoryManager();
> +boolean isUseSimpleLocalRepositoryManager();
>
>  /**
>   * @since 3.1
>   */
> -MavenExecutionRequest setUseSimpleLocalRepostoryManager( boolean
> useSimpleLocalRepostoryManager );
> +

Re: Passing State Between Plugin Executions

[Brian Fox]

The enforcer plugin uses a static array to hold data between executions.


On Wed, Jan 30, 2013 at 2:15 PM, Aaron Dixon  wrote:

> I am developing a plugin with "start" and "stop" goals to be executed
> typically in pre-integration-test and post-integration-test phases,
> respectively.
>
> For example, the "start" execution will discover a port that I'd like the
> "stop" execution to know.
>
> Of course, I could use a file or possibly static state to share this value
> -- but I am wondering if there is a first-class idiom for doing this?
>
> Thanks for any advise!
>

Re: Top navbar on the site with fluido

[Brian Fox]

+1


On Tue, Jan 1, 2013 at 6:42 AM, Anders Hammar  wrote:

> +1
> I think we should keep the old left-hand menu, like what we've done over at
> Mojo.
>
> /Anders
>
>
> On Sat, Dec 29, 2012 at 5:09 PM, Jesse Farinacci  wrote:
>
> > Greetings,
> >
> > On Fri, Dec 28, 2012 at 11:21 PM, Kristian Rosenvold
> >  wrote:
> > > There was a comment about this in the surefire release (
> > > (http://maven.apache.org/surefire/maven-surefire-plugin/),
> > > so I figured we might as well get on with this discussion.
> >
> > I don't disagree with any of what you had to say. I think that the new
> > fluido skin is quite an improvement. However, I find that users
> > respond better to both the old left-nav plus the top-nav system that
> > is optional with the fluido skin.
> >
> > There's a long history in Maven site chronology where navigation is
> > found on the left in a boxy area. To move away from that in just one
> > generation is too much change for users to handle.
> >
> > -Jesse
> >
> > --
> > There are 10 types of people in this world, those
> > that can read binary and those that can not.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Getting Maven component and plugin releases to /dist -- space

[Brian Fox]

On Sun, Dec 23, 2012 at 10:26 AM, Henk P. Penning  wrote:

> On Sun, 23 Dec 2012, Benson Margulies wrote:
>
>  Date: Sun, 23 Dec 2012 15:26:18 +0100
>> From: Benson Margulies 
>> To: Henk P. Penning 
>> Cc: Maven Developers List ,
>> "infrastruct...@apache.org" 
>>
>> Subject: Re: Getting Maven component and plugin releases to /dist -- space
>>
>
> Hi Benson,
>
>   excellent.
>
>   As far as I can see, everything can go directly into
>   "archive.a.o/dist/maven/".
>
>   The only point of having stuff in /dist/ is that projects
>   can refer users/downloaders to that stuff on a mirror.
>   Since there will be no such pointers to the stuff you want
>   to add, there is no point in having it on the mirrors, and
>   therefore in /dist/.
>

I would completely agree with that. But it's not what the policy says. It
says it must go to dist. Do we really mean archives for everything and dist
only for things that are linked from webpages so they can be mirrored?
That's completely sensible.

Re: plugin source releases aren't copied to 'dist', can anyone dig up history?

[Brian Fox]

Further to that, no one will ever consume maven plugins from a random dist
folder anyway, so a policy that requires this is a paper policy only and
would have no basis in the reality of how these particular projects are
consumed.


On Fri, Dec 21, 2012 at 1:18 PM, Brian Fox  wrote:

> The last discussion of this required the production of proper source
> bundles for voting, which we created at that time. I don't recall there
> being any requirement that everything go onto dist.
>
>
> On Fri, Dec 21, 2012 at 10:57 AM, Benson Margulies 
> wrote:
>
>> Dear fellow community members,
>>
>> The current official documentation for Apache releases calls for all
>> releases to be copied to the 'dist' area.
>>
>> We don't do that for poms and plugins. We just push a source release
>> zip to repository.apache.org.
>>
>> Can anyone here help me out by finding a historical thread of
>> discussion that approved this plan of attack?
>>
>> I'm setting out to edit the official page to memorialize this policy
>> for the benefit of other projects, and I'm getting pushback.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: plugin source releases aren't copied to 'dist', can anyone dig up history?

[Brian Fox]

The last discussion of this required the production of proper source
bundles for voting, which we created at that time. I don't recall there
being any requirement that everything go onto dist.


On Fri, Dec 21, 2012 at 10:57 AM, Benson Margulies wrote:

> Dear fellow community members,
>
> The current official documentation for Apache releases calls for all
> releases to be copied to the 'dist' area.
>
> We don't do that for poms and plugins. We just push a source release
> zip to repository.apache.org.
>
> Can anyone here help me out by finding a historical thread of
> discussion that approved this plan of attack?
>
> I'm setting out to edit the official page to memorialize this policy
> for the benefit of other projects, and I'm getting pushback.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Logging

[Brian Fox]

Great summary Benson, I agree with your assessments here.


On Sun, Dec 16, 2012 at 12:16 PM, Benson Margulies wrote:

> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how close we are to a consensus.
>
> In the following, I use the word 'want' to express *preference*, not
> non-negotiable demands.
>
> We all need: reasonable performance, an acceptable license (i.e.
> category A or B), a stable, reliable, logger.
>
> Various of us want: MDCs, colorization: a package with a community
> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
> outputs.
>
> We know that: java.util.logging isn't going to give us MDCs or
> colorization without a great deal of effort. So I'm crossing it off in
> this email.
>
> Now, I'm going to express an opinion based on all the email *I've*
> seen. I don't claim to be right, but I wonder if people would be
> willing to follow my logic.
>
> Once we eliminate j.u.l from consideration, our choices are logback,
> log4j 1.x, and log4j 2.x.
>
> It seems to me that log4j 2.x is not really ready for us yet, so in
> this email I'm crossing it off. If we continue to dither for another
> few months, that might change. If someone disagrees, I'm sure they'll
> respond.
>
> log4j1.x is the tried and true alternative. Colorization, however,
> would require significant effort. Those of us who don't give a fig
> about colourization won't be perturbed by this.
>
> logback, on the other hand, is very widely adopted, and no one seems
> to be able to offer any *technical* objection to it. And it gives us
> colorization out of the box.
>
> The objections to logback, then, are cultural, organizational, and/or
> related to license.
>
> In my view, the very broad adoption of logback seems to me to
> neutralize the concern that it's a one-man-band. While one person
> projects present certain risks in the abstract, this particular one
> seems to me not to raise them.
>
> In my view, objecting based on EPL is, as I wrote once before, not
> appropriate. The Maven project erected a barrier to EPL dependencies
> to respond to cases in which core Maven functionality was forked and
> EPL-ified, or just proposed to be replaced by EPL code. The situation
> with logging is simply not analogous. As a project, I don't think we
> need to anticipate wanting to bring the logging system into our
> source. Adding a category B logging dependency does not contribute to
> the 'hollowing out' of Maven.
>
> As a Foundation, category B licenses are just as acceptable as
> category A licenses as dependencies. (I also wonder why this barrier
> was not specifically set up in terms of 'core code replaced by non-A'
> instead of 'EPL').
>
> If I add this all up, to me it amounts to a test. If some member(s) of
> this community really, really, want to take log4j 1.x in order to 'use
> Apache' or 'have a community', I think that those people should be
> willing to step up and *write the code* to make log4j 1.x
> feature-equivalent with logback for our purposes. The same logic would
> apply to j.u.l, though my impression is that there is no practical
> coding path that gets to equivalence.
>
> I trust that this email will inspire response; perhaps it will inspire
> a response that allows us to detect some consensus.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Logback in Maven Core

[Brian Fox]

On Tue, Dec 11, 2012 at 5:07 PM, Benson Margulies wrote:

>
> If we ever got that far, I would argue pretty strenuously against a
> PMC-level rejection of something just based on being EPL. A class-B
> license is a perfectly legitimate dependency.


As would I. If we were talking about binding our apis against a class-B, I
might feel different, but we aren't. We're talking about using SLF4J as the
api and logback as the implementation. If someone needs to come along and
use a different logger impl, is it that big of a deal?

I'd like to hear from someone who does Linux repackaging of Maven on this
topic...

Re: Maven Core to Git

[Brian Fox]

Didn't it used to be that way? (separate)


On Tue, Nov 27, 2012 at 4:09 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 27 November 2012 08:41, Olivier Lamy  wrote:
>
> > 2012/11/27 Brett Porter :
> > >
> > > On 27/11/2012, at 10:34 AM, Arnaud Héritier 
> wrote:
> > >
> > >> On Mon, Nov 26, 2012 at 11:20 PM, Jason van Zyl 
> wrote:
> > >>
> > >>> I'm going to be working on the core for a few weeks. I am not
> convinced
> > >>> putting the ITs with the core is workable. I've tried it with a few
> > >>> scenarios and it's super confusing to me at least.
> > >>>
> > >>
> > >> +1
> > >
> > > Agree - makes sense to keep them separate as they are often run against
> > different versions of Maven.
> > +1.
> > That will make that a sort of Maven tck.
> >
>
> Which is what it should be IMHO
>
>
> >
> > >
> > > - Brett
> > >
> > > --
> > > Brett Porter
> > > br...@apache.org
> > > http://brettporter.wordpress.com/
> > > http://au.linkedin.com/in/brettporter
> > > http://twitter.com/brettporter
> > >
> > >
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> >
> > --
> > 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: [VOTE] Maven Indexer 5.1.0 Release (take 2)

[Brian Fox]

+1


On Tue, Nov 20, 2012 at 2:15 PM, Tamás Cservenák wrote:

> Hi,
>
> we'd like to release Maven Indexer 5.1.0.
>
> We fixed 7 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112&version=18972
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-051/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> ~t~
>

Re: [VOTE] Move Maven projects sources to git

[Brian Fox]

I'm +1

On Tue, Sep 11, 2012 at 1:39 PM, Robert Scholte wrote:

> I don't think it's IF we should move to git, but WHEN and now seems to be
> the right time.
> +1
>
> Robert
>
> Op Tue, 11 Sep 2012 14:49:46 +0200 schreef Paul Gier :
>
>
>  +1, and I'm willing to volunteer if you still need more people.
>>
>> On 09/05/2012 06:04 AM, Olivier Lamy wrote:
>>
>>> Hi,
>>> This vote is to decide moving our source tree currently located in one
>>> svn repository to git (multiple git repositories).
>>> First, we need to have at least 3 volunteers to help on Apache infra
>>> for this move and more generally on git Apache infrastructure. (if you
>>> are volunteer you must say that with your vote).
>>> The vote will pass on majority (PMC committer) and if we have the
>>> minimum of 3 volunteers !
>>> BTW contributors can express their opinion by a vote too !
>>> The vote will decide on moving all the source tree  (volunteers time
>>> will the main throttle).
>>>
>>> Volunteers will decide on what they move (notification on dev@ is
>>> mandatory).
>>> The goal is to move simple projects first(scm,surefire, indexer,core,
>>> wagon etc..) then plugins (except if Kristian want to start with
>>> plugins immediately :-) )
>>>
>>> Vote open for 72H.
>>>
>>> [+1] Move to git scm
>>> [0] No interest
>>> [-1] don't move to git (please explain why)
>>>
>>>
>>> Thanks,
>>>
>>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@maven.apache.**org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Why do the core its fail massively when using mirrorOf in settings.xml ?

[Brian Fox]

There are lots of tests that are trying to use file based repositories
for certain conditions. This is why in 2.0.9 I had added the
external:* :

external:* matches all repositories except those using localhost or
file based repositories. This is used in conjunction with a repository
manager when you want to exclude redirecting repositories that are
defined for Integration Testing.

Maybe we should update the default setting.xml in the book, but it's
pretty rare that people are using file repos for their ITs (read:
pretty much only maven ;-)  )

On Thu, Aug 23, 2012 at 2:44 PM, Kristian Rosenvold
 wrote:
> When I try to run the maven core IT's with a mirrorOf setting in my
> settings.xml (copy-paste from
> http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html)
> I get all sorts of
> weird & wonderful artifact resolution failures for snapshots inside
> the forked test processes; this happens regardless of which maven 3.x
> version I try to test.
>
> Removing the the setup from settings.xml clearly fixes the problem.
> Can someone explain what is going on, is this a jira issue or WTF ?
>
> Kristian
>
> -
> 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: Maven2 mirror @ netcologne

[Brian Fox]

On Wed, Jul 25, 2012 at 4:19 PM, Brett Porter  wrote:

> On 26/07/2012, at 3:46 AM, Brian Fox wrote:
>
> > On Tue, Jul 24, 2012 at 7:16 PM, Brett Porter  wrote:
> >
> >>
> >> My understanding is that unfortunately Sonatype are not allowing anyone
> >> else to mirror the content directly any more.
> >>
> >
> > Ibiblio disabled the rsync on their own accord because it was thrashing
> > their disks.
>
> That doesn't seem consistent with Joel's response on the ticket. When did
> that happen?
>
> If this is the case, we should establish another "escrow" location.
>
>
>

Let me clarify my statement because it's not opposed to what Joel said,
we're talking about different things. Ibiblio turned off OUTBOUND rsyncs
because too many people where thrashing their disks and chewing up massive
amounts of bandwidth. The INBOUND rsync is still happenning. Because
Central is over 600GB now, even the rsync from us was thrashing both of our
disks so Joel developed a new method that works like this:

Central Staging reaches out to all the forges and does mini rsyncs scoped
by each groupId folder so they aren't causing any real load. We take the
log output from those to get a manifest of the files that changed. They get
added all up and then inserted into the include-files portion of the
outbound rsync to the other central machines and to ibiblio. The net effect
is that it reduces the churn that rsync produces on the systems, speeds up
the sync and still keeps every file updated.

Since the outbound sync doesn't touch that last_updated.txt file, it isn't
being added as a changed file to any of the rsync pushes, hence it appears
outdated on Ibiblio. But if you poke around out there, you'll find that the
components are in fact being updated.

With the move to the CDN, we have moved a massive amount of traffic back
off of Ibiblio because they were previously serving the indexes. I'll ping
them and see if the rsync is possible again.

Re: Maven2 mirror @ netcologne

[Brian Fox]

On Tue, Jul 24, 2012 at 7:16 PM, Brett Porter  wrote:

>
> My understanding is that unfortunately Sonatype are not allowing anyone
> else to mirror the content directly any more.
>

Ibiblio disabled the rsync on their own accord because it was thrashing
their disks.

Central is now on a CDN so parallel mirrors don't really help anymore. See
more here
http://www.sonatype.com/people/2012/07/we-just-kicked-central-performance-and-availability-up-a-notch-with-edgecast/

Central is now being served from a CDN

[Brian Fox]

Just over a year ago we evolved the Central architecture to be globally
load balanced with 2 servers in the US and 2 more in the UK. This year,
we've gone even futher to increase reliability and delivery performance.

We evaluated several options and ultimately settled with Edgecast as the
delivery system. The way the system works is we direct the central dns
queries (repo1, uk, etc) to an Edgcast CNAME. This resolves to the fastest
available server based on your location (this is effectvely what we had
been doing previously with Dyn). The Edgecast network is serving as a
worldwide proxy to serve up the content. If the content isn't available on
the edge, it falls back to a middle tier and finally back our our root
Central servers in the US or UK and then the content is cached along the
way. In this way, the infrastructure backing Central and managing the
inbound syncs, and indexes still functions as it did prior to this change.

There's nothing you need to do to take advantage of the changes, it's
already in place and hopefully the only side effect is faster builds.

There's more info available on my blog:
http://www.sonatype.com/people/2012/07/we-just-kicked-central-performance-and-availability-up-a-notch-with-edgecast/

Thanks,
Brian

Re: Maven Central is probably blocked in China

[Brian Fox]

Niclas, I'm told it's working now. Can you confirm?

On Tue, Jul 10, 2012 at 1:11 PM, Brian Fox  wrote:

> The network team confirmed that this is only Unicom with the issue. They
> are looking at alternate routes that would hopefully work.
>
>
> On Mon, Jul 9, 2012 at 5:31 PM, Niclas Hedhman  wrote:
>
>> Ok, good to know that it is not completely blocked. It is likely that
>> there are multiple FirewallOps across China regions and the (I think)
>> 3 ISPs (China Telecom, China Mobile and Unicom).
>>
>> As I mentioned, the edgecast address couldn't be reached, but the
>> akamai one could.
>>
>> I am personally in downtown Shanghai, using China Unicom's "Fiber To
>> The Building".
>>
>> I am seen as 58.246.154.81 from the outside at the moment, can reach
>> your a978.g1.akamai.net, but not wpc.829D.edgecastcdn.net.
>>
>> I can also VPN to Beijing, to a 163.com datacenter (which I think is a
>> China Telecom subsidiary), having IP number 60.191.221.179. From
>> there, both hosts above are reachable.
>>
>> So, yes, it seems to be regionalized or per ISP (which makes this less
>> of a problem than I thought). I also mentioned that I am personally on
>> VPN and I am not really affected, but developers I have met are not
>> willing to pay for that service and don't have it.
>>
>>
>> Cheers
>> Niclas
>>
>> On Tue, Jul 10, 2012 at 1:58 AM, Brian Fox  wrote:
>> > Niclas,
>> > We are seeing a lot of traffic to Central from China, so this certainly
>> > isn't a case of the Great Firewall blocking everything, rather it seems
>> a
>> > little more localized. Can you send more more info about your source ip
>> and
>> > geo location that we could use to see what's up? Possibly we can get the
>> > traffic routed to a China friendly ip.
>> >
>> > On Mon, Jul 9, 2012 at 12:08 PM, Brian E. Fox 
>> wrote:
>> >>
>> >> Hi Nicolas, this isn't intentional of course. Let me see what I can
>> dig up
>> >> based in your traces.
>> >>
>> >> --Brian (mobile)
>> >>
>> >>
>> >> On Jul 7, 2012, at 11:45 PM, Niclas Hedhman 
>> wrote:
>> >>
>> >> > (I am not subscribed, so please CC me on any responses)
>> >> >
>> >> > I live in China. I normally have a VPN enabled to circumvent various
>> >> > blocking (YouTube, Twitter, ++) that the Chinese government has in
>> >> > place. I normally don't think much about it. But, today I had my
>> >> > computer rebooted and couldn't build a project, because Maven Central
>> >> > couldn't be reached.
>> >> >
>> >> > So, before I realized that my VPN wasn't running I tracerouted a bit.
>> >> >
>> >> > repo1 resolved to
>> >> >
>> >> > niclas:~ niclas$ dig repo1.maven.org | grep "^[a-z]"
>> >> > repo1.maven.org.1751INCNAMEcentral.maven.org.
>> >> > central.maven.org.212INCNAMEcentral02.maven.org.
>> >> > central02.maven.org.7112INCNAME
>> wpc.829D.edgecastcdn.net.
>> >> > wpc.829D.edgecastcdn.net. 3164INCNAME
>> >> > gs1.wpc.edgecastcdn.net.
>> >> > gs1.wpc.edgecastcdn.net. 2292INA68.232.45.253
>> >> >
>> >> > and from that I also tried central01
>> >> >
>> >> > niclas:~ niclas$ dig central01.maven.org | grep "^[a-z]"
>> >> > central01.maven.org.6477INCNAME
>> >> > central01.maven.org.edgesuite.net.
>> >> > central01.maven.org.edgesuite.net. 20877 IN CNAME a978.g1.akamai.net
>> .
>> >> > a978.g1.akamai.net.4INA124.40.42.31
>> >> > a978.g1.akamai.net.4INA124.40.42.6
>> >> >
>> >> > And with tracerouting both (see below), it struck me that VPN might
>> >> > not be enabled and the IP on "edgecastcdn.net" is probably blocked
>> by
>> >> > China potentially serving something they don't like, could be
>> >> > anything... Yeah, China is BAD, we all know that, but shouldn't we
>> >> > (Apache) try to minimize the problem for your ordinary Chinese
>> >> > developer, could be a student, hobbyist, small entrepreneur and so
>> on,
>> >> > who isn't anti-g

Re: Maven Central is probably blocked in China

[Brian Fox]

The network team confirmed that this is only Unicom with the issue. They
are looking at alternate routes that would hopefully work.

On Mon, Jul 9, 2012 at 5:31 PM, Niclas Hedhman  wrote:

> Ok, good to know that it is not completely blocked. It is likely that
> there are multiple FirewallOps across China regions and the (I think)
> 3 ISPs (China Telecom, China Mobile and Unicom).
>
> As I mentioned, the edgecast address couldn't be reached, but the
> akamai one could.
>
> I am personally in downtown Shanghai, using China Unicom's "Fiber To
> The Building".
>
> I am seen as 58.246.154.81 from the outside at the moment, can reach
> your a978.g1.akamai.net, but not wpc.829D.edgecastcdn.net.
>
> I can also VPN to Beijing, to a 163.com datacenter (which I think is a
> China Telecom subsidiary), having IP number 60.191.221.179. From
> there, both hosts above are reachable.
>
> So, yes, it seems to be regionalized or per ISP (which makes this less
> of a problem than I thought). I also mentioned that I am personally on
> VPN and I am not really affected, but developers I have met are not
> willing to pay for that service and don't have it.
>
>
> Cheers
> Niclas
>
> On Tue, Jul 10, 2012 at 1:58 AM, Brian Fox  wrote:
> > Niclas,
> > We are seeing a lot of traffic to Central from China, so this certainly
> > isn't a case of the Great Firewall blocking everything, rather it seems a
> > little more localized. Can you send more more info about your source ip
> and
> > geo location that we could use to see what's up? Possibly we can get the
> > traffic routed to a China friendly ip.
> >
> > On Mon, Jul 9, 2012 at 12:08 PM, Brian E. Fox 
> wrote:
> >>
> >> Hi Nicolas, this isn't intentional of course. Let me see what I can dig
> up
> >> based in your traces.
> >>
> >> --Brian (mobile)
> >>
> >>
> >> On Jul 7, 2012, at 11:45 PM, Niclas Hedhman  wrote:
> >>
> >> > (I am not subscribed, so please CC me on any responses)
> >> >
> >> > I live in China. I normally have a VPN enabled to circumvent various
> >> > blocking (YouTube, Twitter, ++) that the Chinese government has in
> >> > place. I normally don't think much about it. But, today I had my
> >> > computer rebooted and couldn't build a project, because Maven Central
> >> > couldn't be reached.
> >> >
> >> > So, before I realized that my VPN wasn't running I tracerouted a bit.
> >> >
> >> > repo1 resolved to
> >> >
> >> > niclas:~ niclas$ dig repo1.maven.org | grep "^[a-z]"
> >> > repo1.maven.org.1751INCNAMEcentral.maven.org.
> >> > central.maven.org.212INCNAMEcentral02.maven.org.
> >> > central02.maven.org.7112INCNAME
> wpc.829D.edgecastcdn.net.
> >> > wpc.829D.edgecastcdn.net. 3164INCNAME
> >> > gs1.wpc.edgecastcdn.net.
> >> > gs1.wpc.edgecastcdn.net. 2292INA68.232.45.253
> >> >
> >> > and from that I also tried central01
> >> >
> >> > niclas:~ niclas$ dig central01.maven.org | grep "^[a-z]"
> >> > central01.maven.org.6477INCNAME
> >> > central01.maven.org.edgesuite.net.
> >> > central01.maven.org.edgesuite.net. 20877 IN CNAME a978.g1.akamai.net.
> >> > a978.g1.akamai.net.4INA124.40.42.31
> >> > a978.g1.akamai.net.4INA124.40.42.6
> >> >
> >> > And with tracerouting both (see below), it struck me that VPN might
> >> > not be enabled and the IP on "edgecastcdn.net" is probably blocked by
> >> > China potentially serving something they don't like, could be
> >> > anything... Yeah, China is BAD, we all know that, but shouldn't we
> >> > (Apache) try to minimize the problem for your ordinary Chinese
> >> > developer, could be a student, hobbyist, small entrepreneur and so on,
> >> > who isn't anti-government (most people here are quite content with the
> >> > government) to be able to use Apache projects?
> >> >
> >> > The fact is now, that without reasonably reliable access to Maven
> >> > Central, one can not really participate in many, many of the Java
> >> > projects at ASF.
> >> >
> >> > I don't know how the DNS and host resolution is supposed to work, who
> >> > is participating in the hosting and under w

Re: Maven Central is probably blocked in China

[Brian Fox]

Niclas,
We are seeing a lot of traffic to Central from China, so this certainly
isn't a case of the Great Firewall blocking everything, rather it seems a
little more localized. Can you send more more info about your source ip and
geo location that we could use to see what's up? Possibly we can get the
traffic routed to a China friendly ip.

On Mon, Jul 9, 2012 at 12:08 PM, Brian E. Fox  wrote:

> Hi Nicolas, this isn't intentional of course. Let me see what I can dig up
> based in your traces.
>
> --Brian (mobile)
>
>
> On Jul 7, 2012, at 11:45 PM, Niclas Hedhman  wrote:
>
> > (I am not subscribed, so please CC me on any responses)
> >
> > I live in China. I normally have a VPN enabled to circumvent various
> > blocking (YouTube, Twitter, ++) that the Chinese government has in
> > place. I normally don't think much about it. But, today I had my
> > computer rebooted and couldn't build a project, because Maven Central
> > couldn't be reached.
> >
> > So, before I realized that my VPN wasn't running I tracerouted a bit.
> >
> > repo1 resolved to
> >
> > niclas:~ niclas$ dig repo1.maven.org | grep "^[a-z]"
> > repo1.maven.org.1751INCNAMEcentral.maven.org.
> > central.maven.org.212INCNAMEcentral02.maven.org.
> > central02.maven.org.7112INCNAMEwpc.829D.edgecastcdn.net.
> > wpc.829D.edgecastcdn.net. 3164INCNAMEgs1.wpc.edgecastcdn.net
> .
> > gs1.wpc.edgecastcdn.net. 2292INA68.232.45.253
> >
> > and from that I also tried central01
> >
> > niclas:~ niclas$ dig central01.maven.org | grep "^[a-z]"
> > central01.maven.org.6477INCNAME
> central01.maven.org.edgesuite.net.
> > central01.maven.org.edgesuite.net. 20877 IN CNAME a978.g1.akamai.net.
> > a978.g1.akamai.net.4INA124.40.42.31
> > a978.g1.akamai.net.4INA124.40.42.6
> >
> > And with tracerouting both (see below), it struck me that VPN might
> > not be enabled and the IP on "edgecastcdn.net" is probably blocked by
> > China potentially serving something they don't like, could be
> > anything... Yeah, China is BAD, we all know that, but shouldn't we
> > (Apache) try to minimize the problem for your ordinary Chinese
> > developer, could be a student, hobbyist, small entrepreneur and so on,
> > who isn't anti-government (most people here are quite content with the
> > government) to be able to use Apache projects?
> >
> > The fact is now, that without reasonably reliable access to Maven
> > Central, one can not really participate in many, many of the Java
> > projects at ASF.
> >
> > I don't know how the DNS and host resolution is supposed to work, who
> > is participating in the hosting and under what terms. But I think
> > Maven/Sonatype should have in its interest to NOT EXCLUDE some
> > staggering amount of Java programmers, and perhaps try to find a way
> > to get a better SLA here. If you need help from someone to check "from
> > the inside the Great Firewall", just let me know...
> >
> >
> > Cheers
> > Niclas
> >
> >
> > traceroute to gs1.wpc.edgecastcdn.net (68.232.45.253), 64 hops max, 52
> > byte packets
> > 1  192.168.2.1 (192.168.2.1)  1.446 ms  0.980 ms  0.900 ms
> > 2  58.246.152.1 (58.246.152.1)  9.855 ms  11.724 ms  8.662 ms
> > 3  210.22.67.29 (210.22.67.29)  9.563 ms  3.698 ms  1.712 ms
> > 4  112.64.251.165 (112.64.251.165)  1.696 ms  1.819 ms  3.215 ms
> > 5  * * *
> > 6  * * *
> > 7  * * *
> > 8  * * *
> > 9  * * *
> > 10  * * *
> > 11  * * *
> > 12  * * *
> > 13  * * *
> > 14  * * *
> > 15  * * *
> > 16  * * *
> > 17  * * *
> >
> >
> > niclas:qi4j-sdk niclas$ traceroute  central01.maven.org
> > traceroute: Warning: central01.maven.org has multiple addresses; using
> > 209.107.203.19
> > traceroute to a978.g1.akamai.net (209.107.203.19), 64 hops max, 52 byte
> packets
> > 1  192.168.2.1 (192.168.2.1)  1.681 ms  0.910 ms  0.889 ms
> > 2  58.246.152.1 (58.246.152.1)  14.958 ms  14.339 ms  115.382 ms
> > 3  112.64.251.133 (112.64.251.133)  3.516 ms  2.892 ms  1.682 ms
> > 4  112.64.251.165 (112.64.251.165)  2.117 ms  1.934 ms  1.926 ms
> > 5  112.64.243.170 (112.64.243.170)  3.859 ms  8.432 ms  4.110 ms
> > 6  * * *
> > 7  219.158.9.209 (219.158.9.209)  4.284 ms  3.517 ms  6.284 ms
> > 8  219.158.100.194 (219.158.100.194)  32.392 ms  34.428 ms  32.079 ms
> > 9  219.158.96.230 (219.158.96.230)  33.214 ms  33.501 ms  33.470 ms
> > 10  219.158.96.222 (219.158.96.222)  31.660 ms  31.564 ms  33.370 ms
> > 11  sl-st30-sj-0-4-3-3.sprintlink.net (144.228.111.29)  214.116 ms
> > 466.648 ms  503.740 ms
> > 12  sl-st31-sj-0-12-0-3.sprintlink.net (144.232.3.33)  180.679 ms
> >sl-st31-sj-0-8-0-0.sprintlink.net (144.232.3.29)  214.923 ms
>  231.186 ms
> > 13  144.232.8.194 (144.232.8.194)  522.103 ms  381.628 ms  221.618 ms
> > 14  te0-0-0-3.ccr22.sjc01.atlas.cogentco.com (154.54.6.109)  219.036 ms
> >te0-3-0-3.ccr22.sjc01.atlas.cogentco.com (154.54.6.101)  184.460 ms
> >te0-1-0-0.ccr21.sjc03.atlas.cogentco.com (66.28.4.53)  305.247 ms

Re: RPMs for Maven 3?

[Brian Fox]

Has anyone considered making an rpm/deb bundle that essentially
contains a script which can fetch the associated tar.gz from the
apache site and unpack it?

It seems like this would be the best of both worlds. Hardly anything
ever changes in the package, people get easy access to "sudo apt get
install/upgrade maven" and there isn't a big concern about this bundle
being a different beast entirely.

I realize this suggestion might be blasphemy in some circles because
it isn't built again from scratch, yada yada, but it seems like the
hurdle that needs to be solved is simply download and untar the bundle
and set the path and env, and this has nothing to do with rebuilding
and tweaking the package.

my .02


On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee
 wrote:
> Just a suggestion.
>
> If you can find some people who are not currently commuters and are
> interested in do thing just this very thing, could they be a partial
> committer, only working on the RPM's and not the other parts of maven?
>
> In my opinion, this is the spirit of open source software.  I know
> everywhere I have been my IT/OPS wanted RPM's for maven.
>
> Jason
>
> On 3/20/12 7:47 AM, "Stephen Connolly" 
> wrote:
>
>>To get the RPMs released, you are going to have to find 3xPMC members
>>willing to vote +1 for each time you run the release.
>>
>>Your best option is to have the RPMs as a separate module that depends
>>on org.apache.maven:apache-maven and repackages that producing just an
>>RPM.
>>
>>Do not try to integrate it into the core build of Maven, as you will
>>have too few PMC members willing to vote on the RPM being in the core
>>dist.
>>
>>Profiles would be evil for this case... separate module outside of the
>>main build is fine.
>>
>>-Stephen
>>
>>P.S. in case it was not clear from my previous mail, I will not be
>>using what little time I have to vote on RPM releases. There are
>>currently 24 people on the PMC list. If you cannot find at least 3 of
>>them willing to consider voting +1 on RPM releases, then you are SooL
>>
>>On 20 March 2012 14:19, Stanislav Ochotnicky 
>>wrote:
>>>
>>> I would *really* like for maven to produce RPMs as alternative dist
>>> output, but I understand your position. I had a quick look into
>>> rpm-maven-plugin and I believe a reasonable RPM output could be achieved
>>> by using it in with non-default profile. That should also prevent any
>>> problems with building for Windows users (or all that don't really care
>>> about rpm output). Or do you consider even this approach unviable? It's
>>> OK if you do, just want to know if I should keep looking for some
>>> compromise or if it's really out of the question.
>>>
>>> One way or the other I created a simple spec/srpm based on binary maven
>>> release:
>>>
>>> Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec
>>> SRPM URL:
>>>http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm
>>> BINRPM URL:
>>>http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rpm
>>>
>>> I should note that I don't really intend to support this solution. But I
>>> might update this together with maven releases since I assume it should
>>> be fairly easy.
>>>
>>> Another request: would you consider adding bash-completion[1] to maven
>>>sources
>>> someplace? We have a slightly modified version in Fedora.
>>>
>>> [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion
>>>
>>> Quoting Jason van Zyl (2012-03-20 13:33:32)
Stanislav,

If you're going to attempt something do it as an external action that
takes the output of the primary build. Don't make something that
augments the standard build process. That's invasive and for people
building on Windows if problems arise they can't really fix it. If you
make an entirely separate build that can consume the output of the
standard build then people who are interested can take a look, those
who don't care aren't affected. I don't want any specific modifications
made to the existing build process to accommodate RPMs. I think a
separate build would be more useful as it will be specific to the task
at hand and people can use it as they like to produce RPMs for
themselves if they so choose.

On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote:

>
> Quoting Jos Backus (2012-03-19 23:40:43)
>> Hi Manfred,
>>
>> On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser
>> wrote:
>>> Jos,
>>>
>>> I agree with you in the sense that any open source project that
>>>cares about
>>> a wide user base should try to provide packages of its software
>>>that are
>>> useful to as many people as possible.
>>
>> Thanks.
>>>
>>> Therefore e.g. the Jenkins effort to offer all sorts of installs is
>>>laudible
>>> imho.
>>
>> Yes. It increases adoption by lowering the threshold to
>>install/manage
>> the software.
>>
>>> However for Maven this is clearly

Re: Security trouble

[Brian Fox]

On Wed, Mar 21, 2012 at 4:35 AM, Sascha Scholz  wrote:
> Hi,
>
> On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy  wrote:
>> BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
>> or fail directly in 3.0.5
>
> Why not deprecate the id entry then instead of forcing users to set
> both to the same value?
>

The xml parsing of older maven's isn't flexible enough to allow this.

> BTW, I don't see that preemptive authentication makes things worse
> regarding security because an attacker could answer with a 401 to get
> the credentials even without preemptive authentication.
>

Correct.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Security trouble

[Brian Fox]

On Tue, Mar 20, 2012 at 6:28 PM, Olivier Lamy  wrote:
> 2012/3/20 Brian Fox :
>> On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy  wrote:
>>> 2012/3/20 Brian Fox :
>>>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy  wrote:
>>>>
>>>>> Hello Folks,
>>>>>
>>>>> The default preemptive on for GET is probably a bad idea.
>>>>> Imagine the following case, in your settings you have:
>>>>>
>>>>>    
>>>>>      olamy
>>>>>      reallycomplicatedpassword
>>>>>      foo.org
>>>>>    
>>>>>
>>>>> During dependencies resolution, you get a pom with a repository.
>>>>>
>>>>>    
>>>>>      foo.org
>>>>>      http://yourpasswordwillbehacked.org/
>>>>>    
>>>>>
>>>>> So with preemptive or not, you will expose your password to a server
>>>>> you probably don't trust.
>>>>>
>>>>> My idea are:
>>>>> * preemptive off by default for GET
>>>>
>>>>
>>>> +1000
>>>>
>>>>>
>>>>> * adding a url element in server element in the settings. And when
>>>>> using a remote repository send authz only if host:ip match
>>>>>
>>>>
>>>> I'm concerned about compatibility with previous maven versions if we
>>>> do this as it's very common to share settings across different
>>>> versions (think m2 cli + m2e with embedded m3)
>>> Agree too. BTW at least at the beginning will be a [WARN]
>>>>
>>
>> Are you saying that all previous versions of maven just warn on new
>> elements in the settings.xml, or are you going to go back and
>> magically make them warn now? ;-)
> no :-)
>
> BTW do we consider adding a warning in 3.0.5 if id != host and fail in 3.0.6
> or fail directly in 3.0.5

I would start with a warning. It will take time to change poms and settings and
it's not a new concern (ie unrelated to pre-emptive auth). In fact,
this kind of change might make sense to call 3.1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Security trouble

[Brian Fox]

On Tue, Mar 20, 2012 at 5:07 PM, Olivier Lamy  wrote:
> 2012/3/20 Brian Fox :
>> On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy  wrote:
>>
>>> Hello Folks,
>>>
>>> The default preemptive on for GET is probably a bad idea.
>>> Imagine the following case, in your settings you have:
>>>
>>>    
>>>      olamy
>>>      reallycomplicatedpassword
>>>      foo.org
>>>    
>>>
>>> During dependencies resolution, you get a pom with a repository.
>>>
>>>    
>>>      foo.org
>>>      http://yourpasswordwillbehacked.org/
>>>    
>>>
>>> So with preemptive or not, you will expose your password to a server
>>> you probably don't trust.
>>>
>>> My idea are:
>>> * preemptive off by default for GET
>>
>>
>> +1000
>>
>>>
>>> * adding a url element in server element in the settings. And when
>>> using a remote repository send authz only if host:ip match
>>>
>>
>> I'm concerned about compatibility with previous maven versions if we
>> do this as it's very common to share settings across different
>> versions (think m2 cli + m2e with embedded m3)
> Agree too. BTW at least at the beginning will be a [WARN]
>>

Are you saying that all previous versions of maven just warn on new
elements in the settings.xml, or are you going to go back and
magically make them warn now? ;-)

> why not even if not self documented by xml element names :-)
>

See above.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Security trouble

[Brian Fox]

On Tue, Mar 20, 2012 at 12:58 PM, Olivier Lamy  wrote:

> Hello Folks,
>
> The default preemptive on for GET is probably a bad idea.
> Imagine the following case, in your settings you have:
>
>    
>      olamy
>      reallycomplicatedpassword
>      foo.org
>    
>
> During dependencies resolution, you get a pom with a repository.
>
>    
>      foo.org
>      http://yourpasswordwillbehacked.org/
>    
>
> So with preemptive or not, you will expose your password to a server
> you probably don't trust.
>
> My idea are:
> * preemptive off by default for GET


+1000

>
> * adding a url element in server element in the settings. And when
> using a remote repository send authz only if host:ip match
>

I'm concerned about compatibility with previous maven versions if we
do this as it's very common to share settings across different
versions (think m2 cli + m2e with embedded m3)

But there is an issue here that needs to be solved. Perhaps instead of
a new element, we introduce a way such that the id can be a dns entry
and then we only use the credentials if the dns and id match.


ie

   
     foo.org
     http://yourpasswordwillbehacked.org/
   

won't send any credentials, even if asked via a 401 response whereas

   
     foo.org
     http://therealthing.foo.org/repo1
   

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Artifact.isSnapshot definition

[Brian Fox]

The second one looks right to me, this is what I've always used as reference[1]

[1] 
http://www.sonatype.com/people/2008/05/maven-code-how-to-detect-if-you-have-a-snapshot-version/

On Mon, Feb 27, 2012 at 6:41 PM, Robert Scholte
 wrote:
> A couple of issues of the release-plugin have to do with SNAPSHOTs, because
> it uses its own definition, borrowed from  (an old) DefaultArtifact.
>
> However, it seems like there are 2 definitions:
> In DefaultArtifact:
>    public boolean isSnapshot()
>    {
>        return getBaseVersion() != null
>            && ( getBaseVersion().endsWith( SNAPSHOT_VERSION ) ||
> getBaseVersion().equals( LATEST_VERSION ) );
>    }
>
> In ArtifactUtils:
>    public static boolean isSnapshot( String version )
>    {
>        if ( version != null )
>        {
>            if ( version.regionMatches( true, version.length() -
> Artifact.SNAPSHOT_VERSION.length(),
>                                        Artifact.SNAPSHOT_VERSION, 0,
> Artifact.SNAPSHOT_VERSION.length() ) )
>            {
>                return true;
>            }
>            else if ( Artifact.VERSION_FILE_PATTERN.matcher( version
> ).matches() )
>            {
>                return true;
>            }
>        }
>        return false;
>    }
>
>
> It looks to me there should only be one. Do I really have to check both
> definitions or can we merge them somehow?
>
> -Robert
>
> -
> 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: Help me convincing Tomcat to use Maven

[Brian Fox]

>
> If Ant is their primary build tool, then I would suggest helping them
> set up Ant to use Maven Ant Tasks as a starting point. That is a great
> way of enabling an Ant build to deploy the artifacts into a Maven-style
> repository.
>
I would second that. In fact Ant/Ivy both already deploy to Nexus to
there should be plenty of examples in their scripts to use.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [CALL FOR TEST] Apache Maven 3.0.4-RC3 staged

[Brian Fox]

30 minutes is a high enough value that I think we'll be ok. Thanks Olivier.

On Tue, Dec 13, 2011 at 8:53 AM, Olivier Lamy  wrote:
> 2011/12/13 Brett Porter :
>>
>> On 13/12/2011, at 7:38 PM, Olivier Lamy wrote:
>>
>>> Le 13 décembre 2011 09:35, Arnaud Héritier  a écrit :
 Olivier increased it to 30 min
 https://jira.codehaus.org/browse/WAGON-365
 http://svn.apache.org/viewvc?view=revision&revision=1213414

 Thus I suppose we have to prepare another RC ?
 Is there others feedback to listen before launching another RC ?
 Others problems with the RC3 ?
>>>
>>> need a wagon release first.
>>
>> Wouldn't it be possible to do this in Maven, same as the user agent setting?
>
> With something hackhish sure :-)
> I can in DefaultMaven#newRepositorySession L416
> modify/add/manipulate on the fly a XmlPlexusConfiguration and add the
> readTimeout element if not already set.
>
> In wagon trunk I have added more methods in Wagon api level to set
> this timeout (will be better)
>
>>
>> - Brett
>>
>> --
>> Brett Porter
>> br...@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
>
>
> --
> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [CALL FOR TEST] Apache Maven 3.0.4-RC3 staged

[Brian Fox]

> Agree.
> I will add it in release and complete documentation here:
> http://maven.apache.org/guides/mini/guide-http-settings.html


This seems like a pretty big change and not enough people will read
that and start to freak out. If maven worked all this time with no
read timeout, why change it now? I've never been aware of it causing a
problem and this is just begging for all kinds of bug reports and
flaming blogs.


>
>>
>> - Brett
>>
>> --
>> Brett Porter
>> br...@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
>
>
> --
> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )

[Brian Fox]

> Again I start a release process and produce a "candidate for release"
> build with a naming 3.0.4 for 5 days vote.
> Something failed, so it has been fixed and I restarted a vote with a
> second "candidate for release" called 3.0.4 for 5 days vote.
> (retagging etc )
>
> What is the difference with producing something called RC1 (build
> which will never published) and rebuild after some days the SAME thing
> without the RC end naming ?
>
> Sorry but except some marketing naming I don't see any difference in a
> technical point of view (everything can be tracked in the scm).

There's a big difference as we found in the past.

Quoting from myself
(http://www.sonatype.com/people/2008/04/quality-is-not-accidental/)

"The normal release process for Maven is to stage a release, email the
dev list and wait for votes or show stopper issues to occur. The norm
for most releases is 72 hours, but with Maven core releases it was
common to let it bake for a week or more. Based on history, I was
positive that the first few attempts wouldn’t make it through, so we
started with a “pre vote” instead of a vote email.

It seemed that each “pre vote” staged release we posted for dev list
testing showed yet another how come no one noticed that? regression.
It became apparent that we needed more than ever to harness the power
of the full community to squash these regressions. Since tossing out
multiple versions all called “2.0.9″ to such a wide audience was
clearly a bad idea, we started appending -RC[x] to distinguish them.
Additionally, we needed to have a set of operating parameters to guide
this broad level of testing, lest we have chaos in the flood of bug
fix requests."

The point is we need to put something out that is a "release" that the
wider user community will consume and provide feedback on. This has in
the past been very effective at surfacing important issues that won't
be found from people on the dev list, but will be found before the ink
is even dry on the official release.

You can see more of the reasoning here:
http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E

This has pretty much been standard fare since 2.0.9, and I don't see a
good reason to deviate. On the contrary, wagon changes are
particularly hard to fully test out and having more eyes are better.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [CANCELLED] [VOTE] Apache Maven 3.0.4 (take 2)

[Brian Fox]

On Sun, Dec 4, 2011 at 3:37 AM, Olivier Lamy  wrote:
> Hello,
> The vote is cancelled due to the issue found by Dan.
>
> I will restart a vote when a fix will be available.

An RC candidate I hope...

>
>
>
> 2011/12/1 Olivier Lamy :
>> Hello,
>>
>> I'd like to release Apache Maven 3.0.4 (take 2).
>>
>> We fixed 31 issues.
>> See release notes:
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=17215
>>
>> Note the difference with first vote is an upgrade of aether to 1.13.1
>> (to prevent chuncked transfer encoding when deploying md5/sha1 files
>> http(s): mode which is not supported by ngnix).
>>
>> And ref site (http://maven.apache.org/ref/3.0.4/) which now use the
>> new fluido skin (wait sync).
>>
>> The staged repo is available here:
>> https://repository.apache.org/content/repositories/maven-283/
>>
>> The staged distributions are available here:
>> http://people.apache.org/builds/maven/3.0.4/
>>
>> As we are near the week end, the vote will be a 5 days vote.
>>
>> [+1]
>> [0]
>> [-1]
>>
>> Here my +1
>>
>> Thanks,
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Apache Maven 3.0.4 (take 2)

[Brian Fox]

The RCs were started for a very specific reason, to improve the
quality of our releases. Just breezing through this thread, there are
clearly issues with memory and some other stuff here that may be
bigger than we understand in this small testing surface. An RC build
will get more eyes and either confirm these aren't a big deal, or they
are.

Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs:
http://www.sonatype.com/people/2008/04/quality-is-not-accidental/

I'm -1 on a release without some RCs.



On Thu, Dec 1, 2011 at 3:17 PM, John Casey  wrote:
> On 12/1/11 10:27 AM, Olivier Lamy wrote:
>>
>> 2011/12/1 Jörg Schaible:
>>>
>>> Benjamin Bentmann wrote:
>>>
 Olivier Lamy wrote:

> I'd like to release Apache Maven 3.0.4 (take 2).
> [...]
> Note the difference with first vote is an upgrade of aether to 1.13.1


 What about the memory issue that Jörg brought up? Shouldn't we at least
 understand the cause and potential impact on other users before
 continuing the release?
>>>
>>>
>>> Continue, I'll report later, but it seems that there's no regression in
>>> 304
>>> vs 303.
>>
>>
>> Thanks!
>>
>> @Benjamin: I tend to say we must release it (maybe the famous "early
>> and often' :-) ).
>
>
> Early-and-often is great, but it's not an excuse to be lax on quality
> standards. Hudson had some famously horrible releases early on, and I
> suspect they had to do with sacrificing concerns about quality on the altar
> of early-and-often.
>
> An RC would take less than a week more if the code really is ready to go. If
> it's not, then we don't want to release it, do we?
>
>
>> My goal is to provide a release point (stable tagged build) to get
>> feedbacks.
>> Trying to reach/wait the "perfect release" without those feedbacks is
>> IMHO impossible.
>
>
> Actually it's not; the feedback comes by way of RCs. This is why it's so
> important to do RCs for Maven core. Maybe we can skip the RC process on
> plugins (I tend to think a single, quick RC is still a good idea there), but
> the core is far, far more complex. Even with a huge IT set we cannot hope to
> cover all use cases there, so it's simply not enough.
>
> If Jörg's issue doesn't pop up in this staged release, then I'd say let's
> just learn that lesson for next time. It takes a little longer using RCs,
> but it's the ONLY way we've been able to produce releases that weren't
> riddled with regressions in the past. Even with a strong IT suite, it's
> still good practice.
>
> As an aside, we might as well call this staging of 3.0.4 a RC and discuss it
> here as if it was. The main difference is procedural IMO, in that this is a
> [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready
> to go. IMO that's an important distinction, since the 72h time limit is
> lurking nearby, but we'd still want to time-box the review of any RC
>
>
>> The previous "issue" for ngnix users was blocker as some oss forge use
>> it. So I cancel it and restart one (and thanks for the fast aether
>> change).
>> But for such memory issue at least users can change MAVEN_OPTS.
>> My email [1] to Jörg describe various things to test on his private
>> company build (I hope he will have time to provide such feedbacks with
>> a stable maven build)
>>
>>
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>>
>>
>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
>
> -
> 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