Re: LifecycleParticipants in child modules?
On 21 Mar 2015, at 15:23, Jason van Zyl wrote: > Put a test project somewhere and I'm happy to look, I need something I can > debug through to try and help. An extracted test project using the current version of the plugin can be downloaded from: https://dl.dropboxusercontent.com/u/909343/basictile.zip When building with "mvn clean package" you should see the child module: [INFO] [INFO] Building Simple Child testing [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ child --- [INFO] but when using "mvn clean package -pl child": [INFO] --- tiles-maven-plugin: Injecting 1 tiles as intermediary parent artifact's... [INFO] Mixed 'io.repaint.tiles:child:testing' with tile 'io.repaint.tiles:basic-tile:2.2-SNAPSHOT' as it's new parent. [INFO] Mixed 'io.repaint.tiles:basic-tile:2.2-SNAPSHOT' with original parent '(no parent)' as it's new top level parent. [INFO] [INFO] [INFO] [INFO] Building Simple Child testing [INFO] [INFO] > There are several tests for participants in the ITs so I think they are all > right. And I don't believe we broke anything along the way to 3.3.1 either. Seems to (not) happen with 3.2.5 as well - I wouldn't put it past something we've not configured/done right. Cheers Mark signature.asc Description: OpenPGP digital signature
Re: LifecycleParticipants in child modules?
Put a test project somewhere and I'm happy to look, I need something I can debug through to try and help. There are several tests for participants in the ITs so I think they are all right. And I don't believe we broke anything along the way to 3.3.1 either. On Mar 20, 2015, at 9:49 PM, Mark Derricutt wrote: > Hey all, > > A question on life cycle participants - it would seem that they don't appear > to be enabled when called from a child module/reactor build. > I'm not exactly sure what you mean. Again, if have a test project and how you invoked it I'm happy to step through to see if anything is wrong. > I just added the invoker-plugin to the tiles-maven-plugin to add some real > usage cases/tests [1] and it seems that when the child module is run from the > reactor, the tile lifecycle is never used, but if called via -pl child ( > essentially making it a top level project in the build ) then it is, I'd > pasted logs of the two runs to [2]. > > The lifecycle is declared as: > > > org.apache.maven.AbstractMavenLifecycleParticipant > TilesMavenLifecycleParticipant > > io.repaint.maven.tiles.TilesMavenLifecycleParticipant > false > > > org.codehaus.plexus.logging.Logger > default > logger > > > > > in my the META-INF/plexus/components.xml file, does it need some other > configuration to work on children, or is this just something that's > broken/unsupported in Maven ( tested against 3.3.1 ). > > Mark > > [1] https://review.gerrithub.io/#/c/221829/1 > [2] https://gist.github.com/talios/1396df5f46a607bd2fb2 > > -- > Mark Derricutt > http://www.theoryinpractice.net > http://www.chaliceofblood.net > http://plus.google.com/+MarkDerricutt > http://twitter.com/talios > http://facebook.com/mderricutt > Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Lastly, "Impossible." The lamest of the lame excuses! Difficult maybe, or impractical, or too expensive, but rarely is anything impossible. -- Yvon Chouinard, Let my People Go Surfing - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
LifecycleParticipants in child modules?
Hey all, A question on life cycle participants - it would seem that they don't appear to be enabled when called from a child module/reactor build. I just added the invoker-plugin to the `tiles-maven-plugin` to add some real usage cases/tests [1] and it seems that when the child module is run from the reactor, the tile lifecycle is never used, but if called via `-pl child` ( essentially making it a top level project in the build ) then it is, I'd pasted logs of the two runs to [2]. The lifecycle is declared as: org.apache.maven.AbstractMavenLifecycleParticipant TilesMavenLifecycleParticipant io.repaint.maven.tiles.TilesMavenLifecycleParticipant false org.codehaus.plexus.logging.Logger default logger in my the `META-INF/plexus/components.xml` file, does it need some other configuration to work on children, or is this just something that's broken/unsupported in Maven ( tested against 3.3.1 ). Mark [1] https://review.gerrithub.io/#/c/221829/1 [2] https://gist.github.com/talios/1396df5f46a607bd2fb2 -- Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt signature.asc Description: OpenPGP digital signature
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
This can be a candidate of Delta SNAPSHOT JAR. Not much advantages with release version JAR, however useful in Release Candidates RCx. -- View this message in context: http://maven.40175.n5.nabble.com/DISCUSSION-JEP-238-Multi-Version-JAR-Files-tp5829748p5829837.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Idea RFI: Artifact-based repositories
Hi folks, I'd like to feel your temperature wrt the following improvement I would like to make to Maven before I start working on it. *== Artifact-based Reposi**tories* == In Tycho we have these constructs: https://wiki.eclipse.org/Tycho/Reference_Card#Repository_providing_the_context_of_the_build eclipse-indigo p2 http://download.eclipse.org/releases/indigo P2 repositories can be encapsulated in an archive. An archive, naturally, can be available as an artifact in some repo somewhere (including the local one). What would you think about adding something like: eclipse-indigo p2 foo bar 1.2.3-SNAPSHOT tgz true The broad strokes are as follows: * Repo artifact becomes a dependency of an artifact being built on the same terms as its parent would be, i.e. if you can't find parent you can't build same with repo artifact (by default) * If repo (or to reverse the semantics) is false (true), failure to resolve the repository does not lead to a critical failure and reactor proceeeds as if the repository declaration did not occur. * Repo artifact is attempted to be resolved using all of the repositories inherited from parents, ad infinitum, or in the repository declarations prior to the one being considered. Artifact is, otherwise, resolved by standard means. Let me know what you think, -- Arcadiy Ivanov arca...@gmail.com | @arcivanov | https://ivanov.biz https://github.com/arcivanov
[ANNOUNCEMENT] End Of Life of Maven 2.2.1 - Plugins / JDK Roadmap
Dear Maven Users, based on the End of Life of Maven 2.2.1 (a year ago) now the time has come to make the final releases of Apache Maven Plugins which support Maven 2.X. If you continue to use Maven 2.2.1 or earlier you have to be aware of using an completely unsupported Maven version as well as unsupported Maven plugins for the future. If you want to have access to new features and bug fixes it is really necessary to update to new Maven versions. The next Maven version which will go the same way as Maven 2.2.1 will be Maven 3.0.5. We have documented the final releases of plugins which support Maven 2.2.1 in relationship with JDK 1.5. The complete list can be found here: http://maven.apache.org/maven-2.x-eol.html The next step on our roadmap is to lift all plugin versions to 3.0.0 to make clear those plugins will only work with Maven 3.0+ furthermore the Java minimum requirement will be lifted to JDK 1.6 as well. No "rule" without exceptions. Here they come: * maven-site-plugin (Version 3.4) See the docs of the plugin for usage in Maven 2.X * maven-compiler-plugin (Version 3.2) which works with Maven 2.2.1. * maven-plugin-plugin (Version 3.4) which works with Maven 2.2.1 * maven-pmd-plugin (Version 3.4) which works with Maven 2.2.1 but needs JDK 1.6 The following plugins already have the Maven 3.0+ requirement: * maven-scm-publish-plugin (Version 1.1) * maven-shade-plugin (Version 2.3) Currently the plan is to make those plugins which are already at 3.X being lifted to version 3.5.0 for Maven 3.X only: * maven-site-plugin (Version 3.5.0) * maven-compiler-plugin (Version 3.5.0) * maven-plugin-plugin (Version 3.5.0) * maven-pmd-plugin (Version 3.5.0) All other plugins will get a version 3.0.0 to identify Maven 3.X only plugins and the JDK minimum will be 1.6. Example: So to make things more clearer here is an example: Currently we have the maven-clean-plugin with version 2.6.1. This plugin supports Maven 2.2.1 and JDK 1.5 minimum. This plugin will get a new major release with version 3.0.0 which has the Maven minimum 3.0 AND Java minimum 1.6. Kind regards - The Apache Maven Team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version ranges and snapshots
Hi Hervé,
what do you think of the following first patch ? I haven't generated the
corresponding html yet, just throwing some ideas..
Regards,
Jon
Index: pom.apt
===
--- pom.apt (révision 1668105)
+++ pom.apt (copie de travail)
@@ -303,8 +303,14 @@
+-+
* <>, <>, <>:\
- These elements are self-explanatory, and you will see them often. This
trinity represents the coordinate
- of a specific project in time, demarcating it as a dependency of this
project. You may be thinking:
+ You will see these elements often. This trinity is used to compute the
maven coordinate
+ of a specific project in time, demarcating it as a dependency of this
project. The purpose
+ of this computation is to select a version that matches all the
dependency declarations
+ (due to transitive dependencies, there can be multiple dependency
declarations for the
+ same artifact). The values should be:
+* <>, <>: directly the corresponding coordinates
of the dependency.
+* <>: a <> that will be used to compute the
dependency's version.
+ Since the dependency is described by maven coordinates, you may be
thinking:
"This means that my project can only depend upon Maven artifacts!" The
answer is, "Of course, but that's a
good thing." This forces you to depend solely on dependencies that Maven
can manage. There are times,
unfortunately, when a project cannot be downloaded from the central
Maven repository. For example, a project
@@ -388,6 +394,21 @@
In the shortest terms, <<>> lets other projects know that,
when you use this project, you
do not require this dependency in order to work correctly.
+*** {Version Ranges}
+
+ Version Ranges used for the <> element have the following
syntax (TODO only examples??):
+ * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps select
the correct version if it matches all ranges)
+ * (,1.0]: x <= 1.0
+ * [1.0]: Hard requirement on 1.0
+ * [1.2,1.3]: 1.2 <= x <= 1.3
+ * [1.0,2.0): 1.0 <= x < 2.0
+ * [1.5,): x >= 1.5
+ * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are comma-separated
+ * (,1.1),(1.1,): This excludes 1.1 if it is known not to work in
combination with this library
+
+ TODO: describe the pseudo-lexicographical order used above, using major
version, minor version, incremental version, and qualifier.
+ examples: 1.0.0-SNAPSHOT < 1.0.0 ...
+
*** {Exclusions}
Exclusions explicitly tell Maven that you don't want to include the
Jon
On Sun, Feb 15, 2015 at 10:09 PM, Hervé BOUTEMY
wrote:
> Hi Jon,
>
> Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
> > Hi,
> > since there were no answers, I'm not sure I wrote to the correct mailing
> > list for this problem.
> good mailing list, but can of worm :)
>
> > Can anyone direct me to someone who is interested in
> > working on this issue ?
> I can try to work on this once more: perhaps we'll manage to improve
> something
>
> >
> > For info, the docs have been saying the following for 7+ years:
> > "groupId, artifactId, version:
> > These elements are self-explanatory"
> >
> > The version element is *not* self-explanatory, especially regarding
> > interactions between version ranges and *-SNAPSHOTs artifacts.
> you're right: version *in dependencies* is not self explanatory (version in
> Maven coordinates is self explanatory)
> It has a lot of subtle features: preferred vs exact match, version range,
> then
> the question of SNAPSHOTS
>
> >
> > Any thoughts on this matter would be appreciated.
> if you have little patches for the source of the page [1], I can review
> and we
> can work and discuss on it step by step
>
> Regards,
>
> Hervé
>
> [1] https://svn.apache.org/repos/asf/maven/site/trunk/content/apt/pom.apt
>
> > Regards,
> > Jon
> >
> > On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper
> wrote:
> > > Hi,
> > > I'm resurrecting this old thread to ask if it's possible to change
> > > http://maven.apache.org/pom.html to document the current
> implementation
> > > behavior (7+ years old).
> > >
> > > Please see my comment on MNG-3092:
> > >
> http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com.
> > >
> atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36261
> > > 6
> > >
> > > Jon
> > >
> > > Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700
> > >
> > > > Hi,
> > > >
> > > > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
> > > > contrary to the 2.0 design docs:
> > > >
> > > > http://jira.codehaus.org/browse/MNG-3092
> > > >
> > > > Brett, Kenney and myself had a brief discussion on IRC about this:
> > > > Kenney says that the behaviour is theoretically correct (which it
> is),
> > > > although I feel it goes against the practical usage described in the
> > > > docs. The two main choices I can see are:
> > > >
> > > > 1) We stick to the design docs and disallow snapshots in ranges when
> > > > they aren't an explicit boundary, as per the MN
[GitHub] maven-archetype pull request: grammar fix in exception message
GitHub user rtack opened a pull request: https://github.com/apache/maven-archetype/pull/4 grammar fix in exception message "The current project does not built an archetype" --> should be either ""The current project does not build an archetype" or ""The current project has not built an archetype" You can merge this pull request into a Git repository by running: $ git pull https://github.com/rtack/maven-archetype patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-archetype/pull/4.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4 commit bed0d31c9df7b4f148c23d878a2b0e3afb915789 Author: Raphael Ackermann Date: 2015-03-20T17:38:03Z grammar fix in exception message "The current project does not built an archetype" --> should be either ""The current project does not build an archetype" or ""The current project has not built an archetype" --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 loading tests and testing for the existence of methods via reflection. Here, I could say, the JEP makes sense. Rather than doing reflection tricks, you could compile the < 1% of your code base appropriately for the different Java versions you want to support. On the flip side, 99% of the code runs on any Java version. Another such example could be the use of Unsafe in older Java versions and newer API replacements in later versions. Again, the use of this JEP should be limited to a few utility classes in your code. This kind of *extreme* proportionality is where I can support the JEP. Paul Cheers, Paul On Fri, Mar 20, 2015 at 11:31 AM, Robert Scholte wrote: > Also have a look at http://cr.openjdk.java.net/~ > psandoz/jdk9/MultiVersionJar-8u60-9-design.md > it looks more complete and has some additional usecases > > Robert > > Op Fri, 20 Mar 2015 17:24:08 +0100 schreef Jason van Zyl >: > > > I'm just reading http://openjdk.java.net/jeps/238 and I encourage >> everyone else to as well. Mark talked about this at EclipseCon and I'm not >> sure what this buys you. I can see the goals in the JEP but it isn't really >> clear about the problem this JEP is trying to solve. I will pop on the >> mailing list and see if I can get an answer. But immediately I see >> complexity added because the compiler, archiving mechanisms and signing >> mechanism all need to be altered. Maybe it is a benefit, I'm not really >> sure yet but at first blush I can't see it myself. >> >> On Mar 20, 2015, at 12:14 PM, Robert Scholte >> wrote: >> >> I agree on the "feels wrong". >>> >>> I don't think it will become that much heavier, assuming most of the >>> time you don't need multi-version classes in an archive. Now you know for >>> sure that a number of classes won't be used, but in general you always get >>> overhead from classes in jars which aren't used. Every time I use >>> maven-shade-plugin + minimizeJar=true the results are impressive. >>> I'm more worried about the complexity and combination with what we gain >>> with it. >>> >>> thanks, >>> Robert >>> >>> >>> Op Thu, 19 Mar 2015 23:43:12 +0100 schreef Gary Gregory < >>> garydgreg...@gmail.com>: >>> >>> The level of granularity feels wrong. This sounds like it would make jar "heavier", potentially a lot heavier. Another angle would be to manage versions 1-1 with jars, one jar for java 7, one for java 8, and so on. With >1 version in one jar, I am FORCED to download versions of class files I'll never use. That seems like a bad idea baked in. Gary On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte wrote: Hi, > > we've been asked to give our opinion on the JEP 238: Multi-Version JAR > Files > > Here's a quote from Rory O'Donnels e-mail: > --- > It's goal is to extend the JAR file format to allow multiple, JDK > release-specific versions of class > files to coexist in a single file. An additional goal is to backport > the > run-time changes to > JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a > detailed discussion, > please see the corresponding thread on the core-libs-dev mailing list. > [1] > > Please keep in mind that a JEP in the Candidate state is merely an idea > worthy of consideration > by JDK Release Projects and related efforts; there is no commitment > that > it will be delivered in > any particular release. > > Comments, questions, and suggestions are welcome on the corelibs-dev > mailing list. (If you > haven’t already subscribed to that list then please do so first, > otherwise your message will be > discarded as spam.) > > [0] http://openjdk.java.net/jeps/238 > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- > February/031461.html > > --- > > IIUC the original request was to have different version of the same > class > within the same artifact. On the mailinglist I noticed a more > interesting > idea: you need a mechanism to map Classes, Methods or Fields from one > version to the other. > > From a Maven perspective I don't see that much issues with the original > idea. You should already be able to do it right now with a lot of > execution-blocks. > However, I don't see how users would maintain different version of the > same class (within an IDE). > To me this all looks quite complex for rare cases. > If you really want multiple JDK versions of the same artifact, I would > probably split them into classified artifacts. > > Any other comments? > >>
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Also have a look at http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md it looks more complete and has some additional usecases Robert Op Fri, 20 Mar 2015 17:24:08 +0100 schreef Jason van Zyl : I'm just reading http://openjdk.java.net/jeps/238 and I encourage everyone else to as well. Mark talked about this at EclipseCon and I'm not sure what this buys you. I can see the goals in the JEP but it isn't really clear about the problem this JEP is trying to solve. I will pop on the mailing list and see if I can get an answer. But immediately I see complexity added because the compiler, archiving mechanisms and signing mechanism all need to be altered. Maybe it is a benefit, I'm not really sure yet but at first blush I can't see it myself. On Mar 20, 2015, at 12:14 PM, Robert Scholte wrote: I agree on the "feels wrong". I don't think it will become that much heavier, assuming most of the time you don't need multi-version classes in an archive. Now you know for sure that a number of classes won't be used, but in general you always get overhead from classes in jars which aren't used. Every time I use maven-shade-plugin + minimizeJar=true the results are impressive. I'm more worried about the complexity and combination with what we gain with it. thanks, Robert Op Thu, 19 Mar 2015 23:43:12 +0100 schreef Gary Gregory : The level of granularity feels wrong. This sounds like it would make jar "heavier", potentially a lot heavier. Another angle would be to manage versions 1-1 with jars, one jar for java 7, one for java 8, and so on. With >1 version in one jar, I am FORCED to download versions of class files I'll never use. That seems like a bad idea baked in. Gary On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte wrote: Hi, we've been asked to give our opinion on the JEP 238: Multi-Version JAR Files Here's a quote from Rory O'Donnels e-mail: --- It's goal is to extend the JAR file format to allow multiple, JDK release-specific versions of class files to coexist in a single file. An additional goal is to backport the run-time changes to JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a detailed discussion, please see the corresponding thread on the core-libs-dev mailing list. [1] Please keep in mind that a JEP in the Candidate state is merely an idea worthy of consideration by JDK Release Projects and related efforts; there is no commitment that it will be delivered in any particular release. Comments, questions, and suggestions are welcome on the corelibs-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.) [0] http://openjdk.java.net/jeps/238 [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- February/031461.html --- IIUC the original request was to have different version of the same class within the same artifact. On the mailinglist I noticed a more interesting idea: you need a mechanism to map Classes, Methods or Fields from one version to the other. From a Maven perspective I don't see that much issues with the original idea. You should already be able to do it right now with a lot of execution-blocks. However, I don't see how users would maintain different version of the same class (within an IDE). To me this all looks quite complex for rare cases. If you really want multiple JDK versions of the same artifact, I would probably split them into classified artifacts. Any other comments? thanks, 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon - 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: [DISCUSSION] JEP 238: Multi-Version JAR Files
I'm just reading http://openjdk.java.net/jeps/238 and I encourage everyone else to as well. Mark talked about this at EclipseCon and I'm not sure what this buys you. I can see the goals in the JEP but it isn't really clear about the problem this JEP is trying to solve. I will pop on the mailing list and see if I can get an answer. But immediately I see complexity added because the compiler, archiving mechanisms and signing mechanism all need to be altered. Maybe it is a benefit, I'm not really sure yet but at first blush I can't see it myself. On Mar 20, 2015, at 12:14 PM, Robert Scholte wrote: > I agree on the "feels wrong". > > I don't think it will become that much heavier, assuming most of the time you > don't need multi-version classes in an archive. Now you know for sure that a > number of classes won't be used, but in general you always get overhead from > classes in jars which aren't used. Every time I use maven-shade-plugin + > minimizeJar=true the results are impressive. > I'm more worried about the complexity and combination with what we gain with > it. > > thanks, > Robert > > > Op Thu, 19 Mar 2015 23:43:12 +0100 schreef Gary Gregory > : > >> The level of granularity feels wrong. >> >> This sounds like it would make jar "heavier", potentially a lot heavier. >> Another angle would be to manage versions 1-1 with jars, one jar for java >> 7, one for java 8, and so on. With >1 version in one jar, I am FORCED to >> download versions of class files I'll never use. That seems like a bad idea >> baked in. >> >> Gary >> >> On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte >> wrote: >> >>> Hi, >>> >>> we've been asked to give our opinion on the JEP 238: Multi-Version JAR >>> Files >>> >>> Here's a quote from Rory O'Donnels e-mail: >>> --- >>> It's goal is to extend the JAR file format to allow multiple, JDK >>> release-specific versions of class >>> files to coexist in a single file. An additional goal is to backport the >>> run-time changes to >>> JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a >>> detailed discussion, >>> please see the corresponding thread on the core-libs-dev mailing list. [1] >>> >>> Please keep in mind that a JEP in the Candidate state is merely an idea >>> worthy of consideration >>> by JDK Release Projects and related efforts; there is no commitment that >>> it will be delivered in >>> any particular release. >>> >>> Comments, questions, and suggestions are welcome on the corelibs-dev >>> mailing list. (If you >>> haven’t already subscribed to that list then please do so first, >>> otherwise your message will be >>> discarded as spam.) >>> >>> [0] http://openjdk.java.net/jeps/238 >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- >>> February/031461.html >>> >>> --- >>> >>> IIUC the original request was to have different version of the same class >>> within the same artifact. On the mailinglist I noticed a more interesting >>> idea: you need a mechanism to map Classes, Methods or Fields from one >>> version to the other. >>> >>> From a Maven perspective I don't see that much issues with the original >>> idea. You should already be able to do it right now with a lot of >>> execution-blocks. >>> However, I don't see how users would maintain different version of the >>> same class (within an IDE). >>> To me this all looks quite complex for rare cases. >>> If you really want multiple JDK versions of the same artifact, I would >>> probably split them into classified artifacts. >>> >>> Any other comments? >>> >>> thanks, >>> 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 > Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
I agree on the "feels wrong". I don't think it will become that much heavier, assuming most of the time you don't need multi-version classes in an archive. Now you know for sure that a number of classes won't be used, but in general you always get overhead from classes in jars which aren't used. Every time I use maven-shade-plugin + minimizeJar=true the results are impressive. I'm more worried about the complexity and combination with what we gain with it. thanks, Robert Op Thu, 19 Mar 2015 23:43:12 +0100 schreef Gary Gregory : The level of granularity feels wrong. This sounds like it would make jar "heavier", potentially a lot heavier. Another angle would be to manage versions 1-1 with jars, one jar for java 7, one for java 8, and so on. With >1 version in one jar, I am FORCED to download versions of class files I'll never use. That seems like a bad idea baked in. Gary On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte wrote: Hi, we've been asked to give our opinion on the JEP 238: Multi-Version JAR Files Here's a quote from Rory O'Donnels e-mail: --- It's goal is to extend the JAR file format to allow multiple, JDK release-specific versions of class files to coexist in a single file. An additional goal is to backport the run-time changes to JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a detailed discussion, please see the corresponding thread on the core-libs-dev mailing list. [1] Please keep in mind that a JEP in the Candidate state is merely an idea worthy of consideration by JDK Release Projects and related efforts; there is no commitment that it will be delivered in any particular release. Comments, questions, and suggestions are welcome on the corelibs-dev mailing list. (If you haven’t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.) [0] http://openjdk.java.net/jeps/238 [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015- February/031461.html --- IIUC the original request was to have different version of the same class within the same artifact. On the mailinglist I noticed a more interesting idea: you need a mechanism to map Classes, Methods or Fields from one version to the other. From a Maven perspective I don't see that much issues with the original idea. You should already be able to do it right now with a lot of execution-blocks. However, I don't see how users would maintain different version of the same class (within an IDE). To me this all looks quite complex for rare cases. If you really want multiple JDK versions of the same artifact, I would probably split them into classified artifacts. Any other comments? thanks, 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
[ANN] Apache Maven Checkstyle Plugin 2.15 Released
The Maven team is pleased to announce the release of the Apache Maven Checkstyle Plugin, version 2.15 Generates a report on violations of code style and optionally fails the build if violations are detected. http://maven.apache.org/plugins/maven-checkstyle-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-checkstyle-plugin 2.15 Release Notes - Apache Maven Checkstyle Plugin - Version 2.15 Bug * [MCHECKSTYLE-288] NullPointerException during building a multi-module project * [MCHECKSTYLE-250] NPE on tying to load LICENSE.txt resource from non-jar plugin dependencies Improvement * [MCHECKSTYLE-286] Add info on ruleset used in console output * [MCHECKSTYLE-261] Upgrade to Checkstyle 6.1.1 Task * [MCHECKSTYLE-277] Require Java 6 * [MCHECKSTYLE-273] Remove Turbine configuration since it is not used any more Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Suggestions User Information about Maven 2.2.1 EoL / Plugins / JDK
It looks good to me On Thu, Mar 19, 2015 at 8:02 PM, Karl Heinz Marbaise wrote: > Hi, > > nothing more to improve ? > > Kind regards > Karl Heinz Marbaise > On 3/18/15 10:21 PM, Karl Heinz Marbaise wrote: >> >> Hi, >> >> i have incorporated the suggestions/ideas/improvements >> >> https://github.com/khmarbaise/maven2eol/blob/master/message.txt >> >> >> If you have adds/supplementals/etc. please send a pull request or you >> can create an issue... >> >> >> The list of Maven versions / JDK requirements should be listed on the >> download page...IMHO... >> >> Kind regards >> Karl Heinz Marbaise >> >> >> On 3/5/15 7:35 PM, Karl Heinz Marbaise wrote: >>> >>> Hi, >>> >>> here is my suggestions for the user list announcement regarding Maven >>> 2.2.1 EoL / Plugins version lift / JDK etc. >>> >>> Any enhancement / things which should also be mentioned please reply and >>> make appropriate changes / Thinks which i have missed... >>> >>> >>> - >>> Dear Maven Users, >>> >>> based on the End of Life of Maven 2.2.1 (a year ago) now the time has >>> come to make the final releases of Apache Maven Plugins which support >>> Maven 2.X. >>> >>> We have documented the final releases of plugins which support Maven >>> 2.2.1 in relationship with JDK 1.5 >>> >>> The complete list can be found here: >>> >>> http://maven.apache.org/maven-2.x-eol.html >>> >>> The next step on our roadmap is to lift all plugin versions to 3.X to >>> make clear those plugins will only work with Maven 3.0+ furthermore the >>> Java minimum requirement will lifted to JDK 1.6 as well. >>> >>> No "rule" without exceptions. Here they come: >>> >>> >>> * maven-site-plugin (Version 3.4) >>> See the docs of the plugin for usage in Maven 2.X >>> >>> * maven-compiler-plugin (Version 3.2) >>> which works with Maven 2.2.1. >>> >>> * maven-plugin-plugin (Version 3.4) >>> which works with Maven 2.2.1 >>> >>> * maven-pmd-plugin (Version 3.4) >>> which works with Maven 2.2.1 but needs JDK 1.6 >>> >>> >>> The following plugins already have the Maven 3.0+ requirement: >>> >>> * maven-scm-publish-plugin (Version 1.1) >>> * maven-shade-plugin (Version 2.3) >>> >>> >>> So to make things more clearer here is an example: >>> >>> Currently we have the maven-clean-plugin with version 2.6.1. >>> >>> This plugin supports Maven 2.2.1 and JDK 1.5 minimum. >>> >>> This plugin will get a new major release with version 3.0 which has the >>> Maven minimum 3.0 AND Jave minimum 1.6. >>> >>> >>> Kind regards >>> The Apache Maven Team >> >> > > - > 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
[RESULT] [VOTE] Release Apache Maven Checkstyle Plugin version 2.15
Hi, The vote has passed with the following result: +1 (binding): Karl Heinz Marbaise, Dennis Lundberg, Jason van Zyl, Hervé Boutemy I will promote the artifacts to the central repo. Thanks to all the voters! On Sun, Mar 15, 2015 at 8:14 PM, Dennis Lundberg wrote: > Hi, > > We solved 6 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&styleName=Html&version=20762 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-1153/ > https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip > > Source release checksum(s): > maven-checkstyle-plugin-2.15-source-release.zip sha1: > 8b89a4d671f2046d19bc40412521f30fcc977b7f > > Staging site: > http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > -- > Dennis Lundberg -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
