f Maven, not
> 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=v
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 clea
19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
>
>
> -- Original Message --
> From: "Paul Benedict"
> To: "Richard Sand"
> Cc: "ZML-Apache-Maven-Developers"
> Sent: 8/31/2016 1
s,
>
> Richard Sand | CEO
> IDF Connect, Inc.
> 2207 Concord Ave, #359
> Wilmington | Delaware 19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
> -- Original Message ------
> From: "Robert Scholte"
> To: &quo
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
Multi-Re
here will be no such relief in
the case of your proposal.
Cheers,
Paul
On Mon, Aug 29, 2016 at 4:56 PM, Christian Schulte wrote:
> Am 08/29/16 um 23:35 schrieb Paul Benedict:
> > Robert, I am mostly in agreement here. However, the big downside to
> > deploying the calculations is th
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 calculate
> this anymore, but
th 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.
>
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
gra
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
> wrote:
>
> The only (minor?) issue I have with the term "consumer POM" is th
; > any
>>>>> > 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
On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte 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/required?
>
I honest
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. Perha
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 understan
), you can then begin to debate how best to be backward compatible.
Cheers,
Paul
On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte 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
>
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 err
Bernd, okay, I find that sensible. Thanks for pointing that out.
Cheers,
Paul
On Thu, Aug 18, 2016 at 3:05 PM, Bernd Eckenfels
wrote:
> Am Thu, 18 Aug 2016 14:27:38 -0500
> schrieb Paul Benedict :
> > Agreed, but only if your understanding of "do" includes do nothing. I
&
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, which is certainly too
> s
, too. Thank you.
Cheers,
Paul
On Wed, Aug 17, 2016 at 9:34 PM, Christian Schulte 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" packaging type, e
told otherwise.
>
>
> On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov
>> 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
>>>&g
re we're on the same
page. Thanks, Michael.
Cheers,
Paul
On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov 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 should
behooves 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 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 have an idea
>&
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
> wrote:
> > I'm i
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 mess
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
, if possible.
Please let me know anyway which I can help.
Cheers,
Paul
On Mon, Aug 15, 2016 at 2:12 PM, Paul Benedict 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 being proposed a
n Mon, Aug 15, 2016 at 1:16 PM, Michael Osipov 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
>> have doubts for
heers,
Paul
On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov
wrote:
> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>
>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov
>> wrote:
>>
>
> Control of the classpath is the dependency list itself, isn't it?
>>
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
> (JS, images, css) t
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 p
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
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 the
'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
> wrote:
>
> So I noticed that toolchains.xml is always expected to live in my ~/.m2/
>> directory.
&
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 y
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();
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
> wrote:
>
> sure
>>
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
> wrote:
>
> If I may expand this thread to the subject of class loaders, how is it
>> possible that a plugin's own d
stock
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
wrote:
> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict
> wrote:
>
> Hi. It s
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
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 wrote:
> All,
>
> Today I googled for "maven blank webapp archetype" and the top hit is an
> example published using 1.0-alpha-7 o
t forgotten (with
a reference to the MNG ticket).
Cheers,
Paul
On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte 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 is not the way to
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 "hey
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 erro
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 SS
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
> background)
> - yellow is the OSX
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?
>
> I ask, because these
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 Mon, Feb 22, 2016 at 12:57 P
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
> wrote:
> > Hi,
> >
>
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 Jan 2016 23:45:32 +0100
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 the module-info
> &g
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. Per
isted 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 wrote:
> >
> > I am writing regarding this statement: "Ceki may do more commits but it’s
> >
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 c
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 wrote:
> When I go to any of the Wagon provider pages [1], their
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
gt; [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 generate module-info.java
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 that
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
wrote:
> Here is the POM:
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2
ou sure you did'nt miss something ? like wrong artifactId/groupId
> maybe ?
>
>
>
> On Wed, Dec 9, 2015 at 9:41 PM, Paul Benedict
> wrote:
>
> > groupId:artifactId:goal
> >
> > Cheers,
> > Paul
> >
> > On Wed, Dec 9, 2015 at 2:38 PM, Ro
groupId:artifactId:goal
Cheers,
Paul
On Wed, Dec 9, 2015 at 2:38 PM, Robert Scholte 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 <
> pbened...@apache.org>:
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
/build/plugi
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, Mich
eers,
Paul
On Wed, Nov 18, 2015 at 4:23 PM, Paul Benedict 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 18, 2015 at 4:03 PM, Robert
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 start compiling
> projects
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 h
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 you think that i'm mis
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
wrote:
> Typo. I meant Commons Codec.
>
>
> Ch
Typo. I meant Commons Codec.
Cheers,
Paul
On Mon, Nov 16, 2015 at 11:38 AM, Paul Benedict
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, 2015 at 11:37 AM, Gary
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, Tibor Digana
> wrote:
>
ty, either vote
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
wrote:
> On Sun, Nov 15, 2015 at 2:35 PM, Paul Benedict
> wrote:
> > That's how it use to work, but that requires
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, And
.
Cheers,
Paul
On Wed, Oct 28, 2015 at 9:35 AM, Jason van Zyl 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 wrote:
> >
>
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 rea
aul Benedict
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
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 wrote:
>
> > All,
> >
>
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 havin
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
e jira issues in the best way
> possible while retaining backwards compatibility.
>
> Cheers
>
>
> On Tue, Apr 14, 2015 at 4:50 PM, Paul Benedict
> wrote:
> > I don't see this as "forcing" to create modules. This is purely a
> packaging
> > issue, n
eate modules
> because IDEs do not support different JDK levels for source code paths in
> the one module
>
> On 14 April 2015 at 09:32, Arnaud Héritier wrote:
>
> > On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY
> > wrote:
> >
> > > Le lundi 13 avril 2015 12
; is clear, not why not just
> stick to 'java#'?
>
> Gary
>
> On Mon, Apr 13, 2015 at 10:19 AM, Paul Benedict
> wrote:
>
> > This is the example project structure I had in mind:
> >
> > mvjar-example/
> >minjava/
> > src/mai
in parallel with
> 7/8 specific code being used for the JDK that do support them, so I wonder
> 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 :
>
> > Le samedi 11 avr
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
vers
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
load
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" wrote:
> Great, thanks for testing!
>
> jvz
>
> > On Mar 13, 2015, at 3:46 PM, Karl Heinz Marbaise
> wrote:
> >
> > Hi Jason,
> >
> > checked several projects of my own proj
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" wrote:
> Hi,
>
> Time to release Maven 3.3.0!
>
> Here is a link to Jira with 22 issues resolved:
>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&vers
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
wrote:
> I noticed 3.2.6 is becoming filled with lots of interesting enhancements:
>
> * MNG-
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 ${user.
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
> wrote
to
produce one single/prime artifact, otherwise you have to begin specifying
"type" element on your dependencies.
On Dec 17, 2014 1:26 AM, "Stephen Connolly"
wrote:
> On Wednesday, December 17, 2014, Paul Benedict
> wrote:
>
> > With regards to the mythical "
jar 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
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
b
Dec 13, 2014 at 5:00 PM, Michael Osipov 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.
> Otherwi
Not Maven central, distribution (download) sites like Apache's.
Cheers,
Paul
On Sat, Dec 13, 2014 at 4:50 PM, Michael Osipov 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
>
it would inconvenience in a minor way.
>
> On Dec 13, 2014, at 5:27 PM, Paul Benedict 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
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 3
We agreed that each new recut is a new point release.
Cheers,
Paul
On Sat, Dec 13, 2014 at 3:42 PM, Igor Fedorenko 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
> wrote:
> >No, it will be 3.2.4.
> >
> >On
day, December 11, 2014, Anders Hammar
> wrote:
> >>>
> >>> Yes, but I don't think making a specific plugin just for adding zip
> >>>> packaging is optimal. Hence the idea of having it in the assembly
> >>>> plugin.
> >>>&g
be part of the assembly plugin.
>
> /Anders
>
> On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict
> 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 confi
an.rosenv...@gmail.com> wrote:
>
> Probably because people just use the assembly plugin ?
>
> Kristian
>
>
>
> 2014-12-11 6:38 GMT+01:00 Paul Benedict :
> > Recently I needed to create zip artifacts for overlays into WAR. Maven
> > doesn't have support fo
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
1 - 100 of 424 matches
Mail list logo
