Re: Problem sharing objects between extension and plugin

ot > many dare to touch this part but I think we should once we agree on the > expected behavior. > > thanks, > Robert > > [1] https://github.com/stephenc/mng-6209 > [2] > > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2 >

Problem sharing objects between extension and plugin

Good day. I hope this post is acceptable. I don't mean to "cross post" but I think my problem may be too difficult for the common question on the user@ list. I scoured all the MNG tickets regarding extensions and class loading documentation on the Maven site (and elsewhere), but cannot find a

Re: Building jar targeting multiple Java versions, including 9

Delaware 19803 | USA > Office: +1 888 765 1611 | Fax: +1 866 765 7284 > Mobile: +1 267 984 3651 > > > > > -- Original Message -- > From: "Paul Benedict" <pbened...@apache.org> > To: "Richard Sand" <rs...@idfconnect.com> > Cc: &quo

Re: Building jar targeting multiple Java versions, including 9

t; <rfscho...@apache.org> > To: "ZML-Apache-Maven-Developers" <dev@maven.apache.org>; "Paul Benedict" > <pbened...@apache.org> > Sent: 8/31/2016 10:39:52 AM > Subject: Re: Building jar targeting multiple Java versions, including 9 > > Hi

Re: Building jar targeting multiple Java versions, including 9

Robert, I'm responding to dev@maven so we can discuss Maven philosophies... I believe the pattern should be based on a multi-module project. Each module should target the expected JDK version. Then introduce a new "mrjar" type for the parent that knows how to bind them all together into a

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

ll be no such relief in the case of your proposal. Cheers, Paul On Mon, Aug 29, 2016 at 4:56 PM, Christian Schulte <c...@schulte.it> wrote: > Am 08/29/16 um 23:35 schrieb Paul Benedict: > > Robert, I am mostly in agreement here. However, the big downside to > > deploying

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Mon, Aug 29, 2016 at 4:07 PM, Robert Scholte wrote: > I think that all the fields of a dependency are quite complete. Based on > the issues I see with moving forward with Aether is that the (complex) > dependency resolution is done inside Maven. The idea is to not

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

more faith in the consumer-pom/dom, but that also requires talking > with third parties who depend on Central. I'm talking about artifact > repository vendors, IDE vendors and build tool vendors. Together we have > enough experience and should be able to come to a new and better schema. &g

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Last week, I communicated my thoughts on why POM model 4.1.0 should not be introduced in the 3.x series. I said that I believed that forcing two separate lines of development would best be beneficial to the overall code base (which is big!!!). The benefit, so I think, is that 3.x would focus on

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

e-option doesn't exist and would make it all too > complex. > I would say that it is indeed all about dependencies. > > thanks, > Robert > > > On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict <pbened...@apache.org> > wrote: > > The only (minor?) issue I hav

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

;> > information we want, and for sure, I expect to put at least >>>>> description, >>>>> > scm >>>>> > details, issueManagement, license (of course). >>>>> > In your list, there is only constributors that I was not counting on &

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <c...@schulte.it> wrote: > Am 08/24/16 um 00:08 schrieb Paul Benedict: > > POM and a future major version POM? I am hinting at a strategy for > forward > > compatibility. > > Is forward compatibility really needed

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

If to "blow up" is unacceptable, then what is the documented way for a Maven client to deal with a it doesn't fully support? Keyword here is *fully* support. Minus tags and values specific to the 4.1.0 POM schema, a high-percentage of the configuration should be parseable by an older client.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Truthfully, I must say a lot of this conversation sounds much like Subversion's client/server architecture: *) The server has a Repository Format version = "build POM" *) The clients create a Working Copy version on checkout = "consumer POM" *) Two distinct schema series *) A client that

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

e backward compatible. Cheers, Paul On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <c...@schulte.it> wrote: > Am 23.08.2016 um 15:53 schrieb Paul Benedict: > > I advise to not introduce any new POM version in the 3.x series. Please > do > > that in Maven 4.0 where you

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

I advise to not introduce any new POM version in the 3.x series. Please do that in Maven 4.0 where you can blue sky ideas and green field the development. Let the 3.x series be the place to shakeout compatibility concerns in gracefully handling the new POM version (like appropriate warnings and

Re: Discussion: Resource-only artifacts

Bernd, okay, I find that sensible. Thanks for pointing that out. Cheers, Paul On Thu, Aug 18, 2016 at 3:05 PM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > Am Thu, 18 Aug 2016 14:27:38 -0500 > schrieb Paul Benedict <pbened...@apache.org>: > > Agreed, but only if y

Re: Discussion: Resource-only artifacts

On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte wrote: > IMO any artifact with the compile-scope should end up on the classpath. If > such artifact shouldn't end up there, that artifact should have a different > scope. > All current scopes are related to the classpath,

Re: Discussion: Resource-only artifacts

. Thank you. Cheers, Paul On Wed, Aug 17, 2016 at 9:34 PM, Christian Schulte <c...@schulte.it> wrote: > Am 08/17/16 um 21:57 schrieb Paul Benedict: > > to me... but it does raise the bigger issue regarding Maven and > > resource-only artifacts. Except for the "pom&qu

Re: Discussion: Resource-only artifacts

-17 um 22:05 schrieb Paul Benedict: > >> I am in agreement a ZIP file shouldn't be a "second-class type". I do not >> want that either. However, it seems I may have said something that makes >> you believe I am saying otherwise? Can you please let me know what you

Re: Discussion: Resource-only artifacts

n the same page. Thanks, Michael. Cheers, Paul On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2016-08-17 um 21:57 schrieb Paul Benedict: > >> Yes, it is valid for a ZIP to contain class files. However, I don't >> believe >> Maven sho

Re: Discussion: Resource-only artifacts

ves us we get the first non-code type handled correctly. Just my 2 cents. Cheers, Paul On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2016-08-17 um 19:20 schrieb Paul Benedict: > >> I'm in in the thought process of MNG-6080 and MNG-5567, and I ha

Re: Discussion: Resource-only artifacts

es-plugin/ > > You bundle up your resources and then you can unbundle them whenever > you want. Works nice for a lot of shared resources. Licenses, static > code analysis configurations, velocity templates, etc etc etc. > > On Wed, Aug 17, 2016 at 1:20 PM, Paul Benedict <pbened..

New Maven Model version (was Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3))

Moving this discussion to the dev@ list... My advice is for the team to introduce the full functional consumption of a 4.1 POM in Maven 4.0. What should go in the 3.x branch is the appropriate forward-compatible handling -- warning or error -- to allow 3.x users to receive sensible diagnostic

Discussion: Resource-only artifacts

I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea to run by the dev folks here: A ZIP file is a type of resource. A resource artifact gets a new scope to remain in the reactor but does not contribute to the compiling process or runtime environment. It's up to the build to

Re: MNG-5567: Zips on classpath

, if possible. Please let me know anyway which I can help. Cheers, Paul On Mon, Aug 15, 2016 at 2:12 PM, Paul Benedict <pbened...@apache.org> wrote: > This thread is about altering the implementation of MNG-5567. I am unsure > why you think it's unrelated to the new scope; that is be

Re: MNG-5567: Zips on classpath

, Aug 15, 2016 at 1:16 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2016-08-15 um 19:57 schrieb Paul Benedict: > >> I hear different opinions on how to move forward. Robert believes it's >> possible with MPLUGIN-305 (is that really the right ticket #?), but you &g

Re: MNG-5567: Zips on classpath

, Paul On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov <micha...@apache.org> wrote: > Am 2016-08-15 um 17:59 schrieb Paul Benedict: > >> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <micha...@apache.org> >> wrote: >> > > Control of the clas

Re: MNG-5567: Zips on classpath

On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov wrote: > JARs are ZIPs with a different name, no less but a bit more. java(1) > treats ZIP files as first-class citizens. We have taken away to option > previously. People, including me, have abused JARs as resource containers

MNG-5567: Zips on classpath

I would like to reopen MNG-5567 because I find the solution incomplete. As the ticket stands today, any "zip" listed as a dependency will get put on the classpath. The rationale behind that decision was: (a) the classpath supports "zip" extensions (b) there is apparently no harm in automatically

Mojo support for dynamic requiresDependencyResolution?

The @Mojo annotation requires the Resolution Scope to be a static value. Thus far, I haven't found any way to actually dictate this dynamically -- like through a configuration parameter, for example. I understand the use of attribute "requiresDependencyResolution" is meant to resolve dependencies

Re: [DISCUSSION] finishing Aether import: help find a new name

In my own experience regarding the difficulty of naming something, it has always indicated the codebase is too big and multi-functional. Thus, there are two paths to take: 1) Slap a brand name on it because no descriptive name can succinctly capture all the provided functionality 2) Break down

Re: Location of toolchains.xml

; Hi Paul, > > So you're using an old version of Maven ;) > https://maven.apache.org/docs/3.3.1/release-notes.html > > Robert > > > On Mon, 01 Aug 2016 21:42:27 +0200, Paul Benedict <pbened...@apache.org> > wrote: > > So I noticed that toolchains.xml is a

Location of toolchains.xml

So I noticed that toolchains.xml is always expected to live in my ~/.m2/ directory. This is a bit unfortunate for me because I have different versions of Maven on my machine. I actually would like to keep my tools separated in the same way I can separate my settings.xml per installation. What do

Why MavenProject is not an Artifact?

It seems that the Artifact interface could be mostly applied to MavenProject. I eyeball about 70% of the methods could apply. If this seems unreasonable, I think an interface could be refactored out from both of them supporting just these: String getGroupId(); String getArtifactId();

Re: ASM leaking into my plugin build

ndencies to scan, where I would prefer a > solution where the plugin knows if additional scanning of dependencies is > required based on the superclass(es) of the mojo's. > > thanks, > Robert > > > On Mon, 18 Jul 2016 22:20:41 +0200, Robert Scholte <rfscho...@apache.or

Re: ASM leaking into my plugin build

a quick look at the scanner code but can't find a reason why ASM > should be leaking. > > Robert > > > On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict <pbened...@apache.org> > wrote: > > If I may expand this thread to the subject of class loaders, how is it >>

Re: ASM leaking into my plugin build

documentation on this subject [1], but I think more information is needed. [1] http://maven.apache.org/guides/mini/guide-maven-classloading.html Cheers, Paul On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte <rfscho...@apache.org> wrote: > On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedic

ASM leaking into my plugin build

Hi. It seems when I build my maven plugin, ASM is being used to scan for my Mojo annotations. I use ASM internally for my own code. My ASM is the latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin executes. If I downgrade to something less, then there is no interference with the

Re: Banner for deprecated plugin documentation

Any thoughts on this? Could it coincide with the new skinning initiative? Cheers, Paul On Wed, Jun 29, 2016 at 4:31 PM, Paul Benedict <pbened...@apache.org> wrote: > All, > > Today I googled for "maven blank webapp archetype" and the top hit is an > example

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

reference to the MNG ticket). Cheers, Paul On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte <c...@schulte.it> wrote: > Am 07/07/16 um 17:49 schrieb Paul Benedict: > > If there is a change that will prevent a build from working, asking for > > users@ testing

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

If there is a change that will prevent a build from working, asking for users@ testing is not the way to do this. The way to do this is to introduce emit a "warning" first in the next version of Maven, and then convert it to an "error" in the next version after that. We can't just say to users

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Karl, I still believe the user who recommended that MNG-5227 be emitted as a warning (not error) in 3.4 was onto something correct. It's clear people aren't getting any lead time to know that their POM has a problem and thus breaks when using 3.4. Making it a warning now and switching it to an

Banner for deprecated plugin documentation

All, Today I googled for "maven blank webapp archetype" and the top hit is an example published using 1.0-alpha-7 of the Archetype plugin. Unfortunately, I didn't catch that the page was for a plugin version so old. I wasted a good 15 minutes (at least). It would be really useful to include an

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

I'd advise to carefully consider banning the use of green and red since that's the most common form of color blindness. Cheers, Paul On Thu, Jun 16, 2016 at 12:59 PM, Hervé BOUTEMY wrote: > - blue for mojo is not really readable on my machine (Linux on black >

Re: Roadmap Maven 3.4.0

You can find the JIRA Maven Roadmap here: https://issues.apache.org/jira/browse/MNG/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel Cheers, Paul On Tue, Jun 14, 2016 at 3:46 PM, Uwe Barthel wrote: > Hi, > > Is there a clear roadmap for version 3.4.0? >

Re: Julia Antonova is out of office.

Wow. She's back -- back at being away, that is! Cheers, Paul On Mon, Feb 22, 2016 at 12:59 PM, Jesse McConnell wrote: > So where did the wiki page for this end up getting migrated after codehaus > shutdown? > > -- > jesse mcconnell > jesse.mcconn...@gmail.com > > On

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

I'm more curious of the growth of "skip" parameters of plugins. Do they exist really to skip the plugin, or are they really representative of the desire to skip an entire phase? On Jan 25, 2016 7:24 PM, "Christopher" wrote: > On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte

Re: Specifying module paths

Robert, in the SOTM document, it explicitly calls out that Module systems are not required to support multiple versions of a module. Correct me if wrong, but I think you're hinting at that? Cheers, Paul On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte wrote: > Op Thu, 14

Re: [Jigsaw] Fwd: Specifying module paths

> the resulting array will appear in any specific order; they are not, in > > particular, guaranteed to appear in alphabetical order. > > I can confirm this, I've seen different orders for different OS's. > > > > To be honest, I don't know if the order of "requires" in

Re: [Jigsaw] Fwd: Specifying module paths

It sounds like Maven will have to generate many .properties file in a build. 1) Modules to compile main source 2) Modules to compile test source 3) Modules to execute tests 4) And what about forking? I am concerned #4 is going to create issues unless the .properties file name is unique enough.

Re: Log4j Warning

ts to Maven are listed as contributors. > Just as they would for Log4J2. A measure, albeit one, of the overall > diversity of contribution. > > > On Jan 6, 2016, at 5:27 PM, Paul Benedict <pbened...@apache.org> wrote: > > > > I am writing regarding this statement: &qu

Re: Log4j Warning

I am writing regarding this statement: "Ceki may do more commits but it’s certainly not a one man show. 76 contributors for Logback and 8 contributors for Log4J2." The numbers in themselves do not tell a full story. It's in appropriate to conclude that since 76 > 8, therefore logback is a better

Maven Wagon provider docs

When I go to any of the Wagon provider pages [1], their project documentation is absent. Things like generated API reports, source reports, etc. are nowhere online. Is this intended, and how come? [1] https://maven.apache.org/wagon/wagon-providers/wagon-http/ Cheers, Paul

Re: Maven Wagon provider docs

regardless of location. If you really want different links per page, they should be brought down under the breadcrumb of the page. That's my 2 cents. Thanks for listening. Cheers, Paul On Wed, Jan 6, 2016 at 2:44 PM, Paul Benedict <pbened...@apache.org> wrote: > When I go to any of the Wagon

Re: [Jigsaw] classpaths and modulepaths

However, you could theoretically generate module-info.java based on dependencies, if you knew which dependencies were modules. Given that the "what is a module" metadata is not being captured today, you would be required to inspect the contents of the jars in your dependency graph and then add

Re: [Jigsaw] classpaths and modulepaths

ert > > [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html > [2] http://www.mojohaus.org/templating-maven-plugin/ > > > Op Tue, 05 Jan 2016 21:58:42 +0100 schreef Paul Benedict < > pbened...@apache.org>: > > > However, you could theoretically genera

Re: Bug or feature: executing plugin without version

Adrien or Robert, when you have some time, can you please test my example and confirm my findings? Cheers, Paul On Thu, Dec 10, 2015 at 10:50 AM, Paul Benedict <pbened...@apache.org> wrote: > Here is the POM: > > http://maven.apache.org/POM/4.0.0; > xmlns:xsi="http://ww

Re: Bug or feature: executing plugin without version

Are you sure you did'nt miss something ? like wrong artifactId/groupId > maybe ? > > > > On Wed, Dec 9, 2015 at 9:41 PM, Paul Benedict <pbened...@apache.org> > wrote: > > > groupId:artifactId:goal > > > > Cheers, > > Paul > > > >

Bug or feature: executing plugin without version

Scenario: I executed a plugin goal on command line and specified a version (1.5). I then did it again without specifying a version. For the latter, Maven chose the latest version (1.6) from my remote repository. I was curious about the version selection; so I edited my POM and added a

Re: Bug or feature: executing plugin without version

groupId:artifactId:goal Cheers, Paul On Wed, Dec 9, 2015 at 2:38 PM, Robert Scholte <rfscho...@apache.org> wrote: > I'd say bug. Are you using prefix:goal or groupId:artifactId:goal ? > > Robert > > Op Wed, 09 Dec 2015 17:19:32 +0100 schreef Paul Benedict <

Re: Switching Maven HEAD to 3.4.0-SNAPSHOT

I think Maven 4.0 would be better suited for a JDK 8 switch. Now I know 4.0 would imply major new features, but I also think you could make JDK 8 the major new feature of 4.0 -- and introduce your planned enhancements in the minor point releases. Cheers, Paul On Mon, Nov 30, 2015 at 4:15 PM,

Re: Open Test Alliance

Hi Johannes. I am not a committer on the Surefire plugin but I wanted to offer my opinion anyway to you. I took a look at JUnit 5 API. My only criticism is the @Context annotation. I don't think developers should be encouraged to write inner classes for the sake of grouping tests. I believe this

Re: Java 9 - Java Modules aka Jigsaw

I believe the -modulepath option is for specifying a directory, not a jar. Do something like this: javac -modulepath mods YourClass.java Cheers, Paul On Wed, Nov 18, 2015 at 4:03 PM, Robert Scholte wrote: > Hi, > > I've started patching the plexus-compiler so we can

Re: Java 9 - Java Modules aka Jigsaw

eers, Paul On Wed, Nov 18, 2015 at 4:23 PM, Paul Benedict <pbened...@apache.org> wrote: > I believe the -modulepath option is for specifying a directory, not a jar. > Do something like this: > javac -modulepath mods YourClass.java > > > Cheers, > Paul > > On Wed, Nov

Re: [VOTE] Maven 3.3.9

Kudos on mentioning the reporters!! Reporters get less attention than even contributors; it's nice to see both held in esteem. Cheers, Paul On Tue, Nov 17, 2015 at 2:34 PM, Karl Heinz Marbaise wrote: > Hi, > > i have preparete release notes > > Can you take a look if

Re: Java 9 - Java Modules aka Jigsaw

Sorry for a third email But it totally slipped my mind that Java 8 now includes a Base64 equivalent: https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html Cheers, Paul On Mon, Nov 16, 2015 at 11:39 AM, Paul Benedict <pbened...@apache.org> wrote: > Typo. I meant Comm

Re: Java 9 - Java Modules aka Jigsaw

But Commons Code has a Base64 equivalent. Why rely on the Sun version when you can use Apache's? Cheers, Paul On Mon, Nov 16, 2015 at 11:37 AM, Gary Gregory wrote: > Java 8 has a java.util.Base64 class so that one is easy. > > Gary > > On Mon, Nov 16, 2015 at 8:48 AM,

Re: Java 9 - Java Modules aka Jigsaw

Typo. I meant Commons Codec. Cheers, Paul On Mon, Nov 16, 2015 at 11:38 AM, Paul Benedict <pbened...@apache.org> wrote: > But Commons Code has a Base64 equivalent. Why rely on the Sun version when > you can use Apache's? > > > Cheers, > Paul > > On Mon, Nov 16,

Re: How the Lucene PMC manages releases

That's how it use to work, but that requires a double voting process: vote once on the RC and then again if the RC is ready for production. It's easier to just burn the numbers; if it fails, move to the next; otherwise you release what you have. Cheers, Paul On Sun, Nov 15, 2015 at 11:48 AM,

Re: How the Lucene PMC manages releases

it down or the RM should ask for Alpha/Beta/GA qualities in the voting thread. Cheers, Paul On Sun, Nov 15, 2015 at 2:13 PM, Benson Margulies <bimargul...@gmail.com> wrote: > On Sun, Nov 15, 2015 at 2:35 PM, Paul Benedict <pbened...@apache.org> > wrote: > > T

Re: [VOTE] Maven 3.3.7

eers, Paul On Wed, Oct 28, 2015 at 9:35 AM, Jason van Zyl <ja...@tesla.io> wrote: > If I put them in the backlog I will completely forget about them. If > someone else wants to shuffle the issues go for it. > > jvz > > > On Oct 28, 2015, at 7:32 AM, Paul Benedict <pben

Re: [VOTE] Maven 3.3.7

FYI, 14 unresolved issues need to move to 3.3.x to make the JIRA list correct. PS: Instead of moving the unresolved forward to a 3.3.8 bucket, how come they aren't put in the Backlog? It would save churn. The Backlog should be cherry-picked and tickets pulled into the next release when work is

Re: Preventing unnecessary JIRA version managing

Benedict pbened...@apache.org wrote: No, but that would be even easier. Cheers, Paul On Wed, Jul 22, 2015 at 10:55 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote

Re: Preventing unnecessary JIRA version managing

No, but that would be even easier. Cheers, Paul On Wed, Jul 22, 2015 at 10:55 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote: All, I noticed that the next set

Preventing unnecessary JIRA version managing

All, I noticed that the next set of unresolved tickets are always assigned a version number. This leads to unnecessary maintenance when we have to burn a point release (i.e., you have to re-assign them to the next release) or it's just time for a new point release. There's really no point in

Plugin list and Codehaus

Since Codehaus is retired, the plugin list [1] pointing there should probably be removed. Thoughts? [1] https://maven.apache.org/plugins/index.html Cheers, Paul

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

compatibility. Cheers On Tue, Apr 14, 2015 at 4:50 PM, Paul Benedict pbened...@apache.org wrote: I don't see this as forcing to create modules. This is purely a packaging issue, not a programming issue. Rather than providing distinct jars per the Java version you're targeting (which people

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

different JDK levels for source code paths in the one module On 14 April 2015 at 09:32, Arnaud Héritier aherit...@gmail.com wrote: On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit : This is the example

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

, not why not just stick to 'java#'? Gary On Mon, Apr 13, 2015 at 10:19 AM, Paul Benedict pbened...@apache.org wrote: This is the example project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

such a multi-module setup would work in this scenario, or would need yet another maven module for tests :'( 2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr: Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit : I've been giving this subject lots of thought in some of spare

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

I've been giving this subject lots of thought in some of spare time. IMO, the most straightforward way of meeting the requirement of the MVJAR is to break up one's JAR project into separate modules. One module would contain the version independent code, and then other modules would be per Java

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

I think a use-case that supports the JEP would be the Spring Framework. They are typically supporting a couple versions of Java at once *in one release* and they have some utility code to access the latest features *if* they are available in the running JRE. However, to do that, they use class

Re: [VOTE] Maven 3.3.1 Release

There are about ten unresolved issues that need to be kicked out of this version. On Mar 13, 2015 7:14 PM, Jason van Zyl ja...@tesla.io wrote: Great, thanks for testing! jvz On Mar 13, 2015, at 3:46 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Jason, checked several projects

Re: [VOTE] Maven 3.3.0 Release

What about the two open issues? Are they fixed in this release or need to be moved? On Mar 11, 2015 5:58 PM, Jason van Zyl ja...@takari.io wrote: Hi, Time to release Maven 3.3.0! Here is a link to Jira with 22 issues resolved:

Re: 3.2.6 - 3.3?

Just following up. I saw at about 5 people expressed their positive preference for this in another thread. Jason, WDYT? Cheers, Paul On Mon, Feb 23, 2015 at 11:30 AM, Paul Benedict pbened...@apache.org wrote: I noticed 3.2.6 is becoming filled with lots of interesting enhancements: * MNG

3.2.6 - 3.3?

I noticed 3.2.6 is becoming filled with lots of interesting enhancements: * MNG-5771 user-configurable core extensions mechanism * MNG-5767 project-specific default jvm options and command line parameters * MNG-3891 Modify maven-toolchain to look in ${maven.home}/conf/toolchains.xml and in

Re: MNG-1683: Zip packaging

one single/prime artifact, otherwise you have to begin specifying type element on your dependencies. On Dec 17, 2014 1:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org wrote: With regards to the mythical assembly

Re: MNG-1683: Zip packaging

Yes, this definitely helps, Stephen. Thanks for your detailed and well-written explanation. I appreciate it much. Cheers, Paul On Wed, Dec 17, 2014 at 9:22 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org wrote

Re: MNG-1683: Zip packaging

always seemed a bit weird. manfred Stephen Connolly wrote on 11.12.2014 07:14: either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org wrote: I am

Re: Releases, Continuous Delivery and the Future

Jason, thanks for taking the time to write this up. It is a good read. One extra tidbit I'd like to discussion is this. When I recommended we burn the version when the vote/build fails, I wasn't expecting we would move the fixed issues to the new version. Let's not do that. I find that confusing

Re: [VOTE] Maven 3.2.4 Release

We agreed that each new recut is a new point release. Cheers, Paul On Sat, Dec 13, 2014 at 3:42 PM, Igor Fedorenko i...@ifedorenko.com wrote: Why? How will we tell the original broken binaries from the new ones? On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io wrote: No,

Re: [VOTE] Maven 3.2.4 Release

When the 3.2.0 build had a regression, we jumped to 3.2.1: http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E Sorry I didn't provide this thread up front. It took a while to find it. However, I am pretty sure we did this again with

Re: [VOTE] Maven 3.2.4 Release

way. On Dec 13, 2014, at 5:27 PM, Paul Benedict pbened...@apache.org wrote: When the 3.2.0 build had a regression, we jumped to 3.2.1: http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E Sorry I didn't provide this thread up

Re: [VOTE] Maven 3.2.4 Release

Not Maven central, distribution (download) sites like Apache's. Cheers, Paul On Sat, Dec 13, 2014 at 4:50 PM, Michael Osipov micha...@apache.org wrote: Am 2014-12-13 um 23:46 schrieb Paul Benedict: I can see your point. However, I don't think it's all that unusual for people to see skipped

Re: [VOTE] Maven 3.2.4 Release

at 5:00 PM, Michael Osipov micha...@apache.org wrote: Am 2014-12-13 um 23:52 schrieb Paul Benedict: Not Maven central, distribution (download) sites like Apache's. I am aware of that but if something has gone GA, it is on Central. Otherwise the term 'GA' wouldn't hold true. Michael

Re: MNG-1683: Zip packaging

always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net

MNG-1683: Zip packaging

Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay?

Re: MNG-1683: Zip packaging

people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why

Re: MNG-1683: Zip packaging

of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase

  1   2   3   4   5   >