Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit : This is the example project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote: I expect we could run the unit test suite on JDK 6 / 7 / 8 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 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 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 version. more precisely: the first module would contain the source for minimum Java version: sometimes, it will contain code that won't run with later JRE This kind of slicing is necessary because you do need different kinds of compiler directives (like -source), different JREs to run unit tests differently, and most importantly, the different JREs to allow debugging according to the Java version you want to test. The other piece that doesn't yet exist is a way to bundle the modules into one jar. Perhaps this can be accomplished by introducing a new mvjar Maven type. I didn't imagine this scenario: no Maven plugins updates nor IDE, just a new feature to merge multiple modules into on MV jar interesting idea, in fact: this would seriously reduce the impact on tooling, even if the result is less compact, ie creates a lot of Maven modules and I am wondering what unit tests will look like for additional versions: the good thing is that they can be tweaked easily. Then bad thing is that we may end up in copy/pasting them Regards, Hervé Paul Cheers, Paul On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a
[RESULT] [VOTE] Release Apache Maven Verifier Plugin version 1.1
Hi, The vote has passed with the following result: +1 (binding): Karl Heinz Marbaise, Hervé Boutemy, Oliver Lamy +1 (non binding): none I will promote the artifacts to the central repo. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Verifier Plugin version 1.1
Hi, I need one more binding VOTE ? Kind regards Karl Heinz Marbaise On 4/10/15 8:07 PM, Karl Heinz Marbaise wrote: Hi, We solved 4 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318120version=12331744 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project+%3D+MVERIFIER+AND+status+%3D+Open+ORDER+BY+priority+DESC Staging repo: https://repository.apache.org/content/repositories/maven-1166 https://repository.apache.org/content/repositories/maven-1166/org/apache/maven/plugins/maven-verifier-plugin/1.1/maven-verifier-plugin-1.1-source-release.zip Source release checksum(s): maven-verifier-plugin-1.1-source-release.zip sha1: 68b08332b15e464b524d6c899f733c167a9ab3ab Staging site: http://maven.apache.org/plugins-archives/maven-verifier-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 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Web Site
On 14 April 2015 at 16:11, Hervé BOUTEMY herve.bout...@free.fr wrote: wow, impressive! Definitely agree!!! what I don't like is that it does not use my wide screen, which is not great on some key pages like http://maven.matsuo-it.com/#/plugins/index.html I wonder what sort of resolution you're using?? :-) I wonder if it could be possible to have atfix for left menu? and a mix of atfix and scroll spy for right one? See http://getbootstrap.com/javascript/#scrollspy and http://getbootstrap.com/javascript/#affix but there are a lot of great ideas that proves people can create great skins! Regarding Jekyll and asciidoctor, I have in my todo list to draw a picture of how maven-site-plugin currently uses reports, Doxia and Doxia SiteTools to render a site with a skin I'm convinced we can replace Doxia SiteTools without wreaking havoc What I still don't know is if Jekyll and/or asciidoctor know about a notion of skin, ie reusable template I will be offline for somthing like 3 weeks: I hope to draw a first draft of the picture to let time thinking about its improvement during my vacation :) Then for the current skins rd, I won't be available at the moment But definitely, it's something really interesting: I don't know if we have something like a skins-community to share skins Nothing at http://maven.apache.org/skins/index.html But http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html links Examples of Existing Skins to http://docs.codehaus.org/display/MAVENUSER/Maven+Skins Notice this is a Codehaus MAVENUSER Confluence content, that will disappear when Codehaus shuts down: seems like we'll need to migrate at least part of it, I don't know how, to ASF... And I hope we can have external contributors on ASF Confluence: once again I don't know I'll try to see what I can do before going offline... Regards, Hervé Le mardi 14 avril 2015 00:58:16 Marek Romanowski a écrit : Hi, I saw Karl's mail about Maven Web Site and I've decided to post some questions to you all. A few months ago I was thinking about how hard would it be to provide modern theme for maven generated sites. I wanted to have full project documentation within project, ideally generated with standard maven tools. Documentation should be usable on mobile devices, and extremely data centric, without any distracting parts. First I've found reflow skin, and basing on it I've created clone that uses Bootstrap 3.3 - http://tunguski.github.io/msb3-maven-skin (not deployed in maven central). But I found working with custom maven site generation extremely hard, especially when you compare it to tools like Jekyll. So I started a research project asking how hard would it be to create totally new theme without changing default maven site generation. I've created proof of concept visible here: http://maven.matsuo-it.com. Full source code is availible on github: https://github.com/tunguski/angular-boostrapize-maven-site. Generally it is starndard maven site data, but themed using bootstrap 3.3. It uses Angular 1.4 for data extraction (from original site), adding dynamic elements like menu generation, scroll to top etc. At this point it probably won't index in search engines at all. Goals achieved in most part: * it looks and works really well on all kinds of devices * it has themes changed in seconds - you may choose a skin and highlighting theme (upper right corner of the screen) * it creates additional menu builded from headers in page content * it unifies theme for sites created with default and fluido skin * it tries to provide fresh view on javadocs and java sources (it's far from perfect) * it adds simple search of artifacts from search.maven.org * it provides proof of concept for dynamic report basing on maven web site data - broken links report: http://maven.matsuo-it.com/#/_views/reports/linkage.html Main things that are broken are in-page anchors, no images, breadcrumb and page title generation (all listed in readme.md). Ok, after that very long introduction I'd like to ask you what do you think about this simple rd. I'm especially interested in: * What do you think about these themes and layout in context of maven site? * Would it be useful for Maven community in any part if some specific things were finnished? If yes, what could be done? Kind Regards, Marek Romanowski. ps.: As it is my first mail on this list, I'd like to thank you all for outstanding work you are doing! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Maven Web Site
wow, impressive! what I don't like is that it does not use my wide screen, which is not great on some key pages like http://maven.matsuo-it.com/#/plugins/index.html but there are a lot of great ideas that proves people can create great skins! Regarding Jekyll and asciidoctor, I have in my todo list to draw a picture of how maven-site-plugin currently uses reports, Doxia and Doxia SiteTools to render a site with a skin I'm convinced we can replace Doxia SiteTools without wreaking havoc What I still don't know is if Jekyll and/or asciidoctor know about a notion of skin, ie reusable template I will be offline for somthing like 3 weeks: I hope to draw a first draft of the picture to let time thinking about its improvement during my vacation :) Then for the current skins rd, I won't be available at the moment But definitely, it's something really interesting: I don't know if we have something like a skins-community to share skins Nothing at http://maven.apache.org/skins/index.html But http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html links Examples of Existing Skins to http://docs.codehaus.org/display/MAVENUSER/Maven+Skins Notice this is a Codehaus MAVENUSER Confluence content, that will disappear when Codehaus shuts down: seems like we'll need to migrate at least part of it, I don't know how, to ASF... And I hope we can have external contributors on ASF Confluence: once again I don't know I'll try to see what I can do before going offline... Regards, Hervé Le mardi 14 avril 2015 00:58:16 Marek Romanowski a écrit : Hi, I saw Karl's mail about Maven Web Site and I've decided to post some questions to you all. A few months ago I was thinking about how hard would it be to provide modern theme for maven generated sites. I wanted to have full project documentation within project, ideally generated with standard maven tools. Documentation should be usable on mobile devices, and extremely data centric, without any distracting parts. First I've found reflow skin, and basing on it I've created clone that uses Bootstrap 3.3 - http://tunguski.github.io/msb3-maven-skin (not deployed in maven central). But I found working with custom maven site generation extremely hard, especially when you compare it to tools like Jekyll. So I started a research project asking how hard would it be to create totally new theme without changing default maven site generation. I've created proof of concept visible here: http://maven.matsuo-it.com. Full source code is availible on github: https://github.com/tunguski/angular-boostrapize-maven-site. Generally it is starndard maven site data, but themed using bootstrap 3.3. It uses Angular 1.4 for data extraction (from original site), adding dynamic elements like menu generation, scroll to top etc. At this point it probably won't index in search engines at all. Goals achieved in most part: * it looks and works really well on all kinds of devices * it has themes changed in seconds - you may choose a skin and highlighting theme (upper right corner of the screen) * it creates additional menu builded from headers in page content * it unifies theme for sites created with default and fluido skin * it tries to provide fresh view on javadocs and java sources (it's far from perfect) * it adds simple search of artifacts from search.maven.org * it provides proof of concept for dynamic report basing on maven web site data - broken links report: http://maven.matsuo-it.com/#/_views/reports/linkage.html Main things that are broken are in-page anchors, no images, breadcrumb and page title generation (all listed in readme.md). Ok, after that very long introduction I'd like to ask you what do you think about this simple rd. I'm especially interested in: * What do you think about these themes and layout in context of maven site? * Would it be useful for Maven community in any part if some specific things were finnished? If yes, what could be done? Kind Regards, Marek Romanowski. ps.: As it is my first mail on this list, I'd like to thank you all for outstanding work you are doing! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Web Site
Le mardi 14 avril 2015 16:34:18 Olivier Lamy a écrit : On 14 April 2015 at 16:11, Hervé BOUTEMY herve.bout...@free.fr wrote: wow, impressive! Definitely agree!!! what I don't like is that it does not use my wide screen, which is not great on some key pages like http://maven.matsuo-it.com/#/plugins/index.html I wonder what sort of resolution you're using?? :-) no secret: 1920x1200 = good screen for a desktop, I'm sure some laptops are not that far, isn't it? What resolution do other devs have? And in fact, whatever the resolution is, nowadays we have wide screens: I don't like when a layout just don't use it :) I wonder if it could be possible to have atfix for left menu? and a mix of atfix and scroll spy for right one? See http://getbootstrap.com/javascript/#scrollspy and http://getbootstrap.com/javascript/#affix but there are a lot of great ideas that proves people can create great skins! Regarding Jekyll and asciidoctor, I have in my todo list to draw a picture of how maven-site-plugin currently uses reports, Doxia and Doxia SiteTools to render a site with a skin I'm convinced we can replace Doxia SiteTools without wreaking havoc What I still don't know is if Jekyll and/or asciidoctor know about a notion of skin, ie reusable template I will be offline for somthing like 3 weeks: I hope to draw a first draft of the picture to let time thinking about its improvement during my vacation :) Then for the current skins rd, I won't be available at the moment But definitely, it's something really interesting: I don't know if we have something like a skins-community to share skins Nothing at http://maven.apache.org/skins/index.html But http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.h tml links Examples of Existing Skins to http://docs.codehaus.org/display/MAVENUSER/Maven+Skins Notice this is a Codehaus MAVENUSER Confluence content, that will disappear when Codehaus shuts down: seems like we'll need to migrate at least part of it, I don't know how, to ASF... And I hope we can have external contributors on ASF Confluence: once again I don't know I'll try to see what I can do before going offline... Regards, Hervé Le mardi 14 avril 2015 00:58:16 Marek Romanowski a écrit : Hi, I saw Karl's mail about Maven Web Site and I've decided to post some questions to you all. A few months ago I was thinking about how hard would it be to provide modern theme for maven generated sites. I wanted to have full project documentation within project, ideally generated with standard maven tools. Documentation should be usable on mobile devices, and extremely data centric, without any distracting parts. First I've found reflow skin, and basing on it I've created clone that uses Bootstrap 3.3 - http://tunguski.github.io/msb3-maven-skin (not deployed in maven central). But I found working with custom maven site generation extremely hard, especially when you compare it to tools like Jekyll. So I started a research project asking how hard would it be to create totally new theme without changing default maven site generation. I've created proof of concept visible here: http://maven.matsuo-it.com. Full source code is availible on github: https://github.com/tunguski/angular-boostrapize-maven-site. Generally it is starndard maven site data, but themed using bootstrap 3.3. It uses Angular 1.4 for data extraction (from original site), adding dynamic elements like menu generation, scroll to top etc. At this point it probably won't index in search engines at all. Goals achieved in most part: * it looks and works really well on all kinds of devices * it has themes changed in seconds - you may choose a skin and highlighting theme (upper right corner of the screen) * it creates additional menu builded from headers in page content * it unifies theme for sites created with default and fluido skin * it tries to provide fresh view on javadocs and java sources (it's far from perfect) * it adds simple search of artifacts from search.maven.org * it provides proof of concept for dynamic report basing on maven web site data - broken links report: http://maven.matsuo-it.com/#/_views/reports/linkage.html Main things that are broken are in-page anchors, no images, breadcrumb and page title generation (all listed in readme.md). Ok, after that very long introduction I'd like to ask you what do you think about this simple rd. I'm especially interested in: * What do you think about these themes and layout in context of maven site? * Would it be useful for Maven community in any part if some specific things were finnished? If yes, what could be done? Kind Regards, Marek
Re: Maven Web Site
On 14 April 2015 at 16:50, Hervé BOUTEMY herve.bout...@free.fr wrote: Le mardi 14 avril 2015 16:34:18 Olivier Lamy a écrit : On 14 April 2015 at 16:11, Hervé BOUTEMY herve.bout...@free.fr wrote: wow, impressive! Definitely agree!!! what I don't like is that it does not use my wide screen, which is not great on some key pages like http://maven.matsuo-it.com/#/plugins/index.html I wonder what sort of resolution you're using?? :-) no secret: 1920x1200 = good screen for a desktop, I'm sure some laptops are not that far, isn't it? What resolution do other devs have? Something a bit similar except laptop have smaller screens. Anyway that's not the problem :-) And in fact, whatever the resolution is, nowadays we have wide screens: I don't like when a layout just don't use it :) Perso I don't think a big page ( with a screen full of text, images etc..) is useful neither human readable. Here we talk about documentation so users just want to find the information ASAP. And sometimes (IMHO) in pages fully fill in the screen it's just a pain. But hopefully it turns to be a pattern/tendency for a lot of web sites (even the most used web site in the world use it :-) ) Again that's a personal opinion :-) I wonder if it could be possible to have atfix for left menu? and a mix of atfix and scroll spy for right one? See http://getbootstrap.com/javascript/#scrollspy and http://getbootstrap.com/javascript/#affix but there are a lot of great ideas that proves people can create great skins! Regarding Jekyll and asciidoctor, I have in my todo list to draw a picture of how maven-site-plugin currently uses reports, Doxia and Doxia SiteTools to render a site with a skin I'm convinced we can replace Doxia SiteTools without wreaking havoc What I still don't know is if Jekyll and/or asciidoctor know about a notion of skin, ie reusable template I will be offline for somthing like 3 weeks: I hope to draw a first draft of the picture to let time thinking about its improvement during my vacation :) Then for the current skins rd, I won't be available at the moment But definitely, it's something really interesting: I don't know if we have something like a skins-community to share skins Nothing at http://maven.apache.org/skins/index.html But http://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.h tml links Examples of Existing Skins to http://docs.codehaus.org/display/MAVENUSER/Maven+Skins Notice this is a Codehaus MAVENUSER Confluence content, that will disappear when Codehaus shuts down: seems like we'll need to migrate at least part of it, I don't know how, to ASF... And I hope we can have external contributors on ASF Confluence: once again I don't know I'll try to see what I can do before going offline... Regards, Hervé Le mardi 14 avril 2015 00:58:16 Marek Romanowski a écrit : Hi, I saw Karl's mail about Maven Web Site and I've decided to post some questions to you all. A few months ago I was thinking about how hard would it be to provide modern theme for maven generated sites. I wanted to have full project documentation within project, ideally generated with standard maven tools. Documentation should be usable on mobile devices, and extremely data centric, without any distracting parts. First I've found reflow skin, and basing on it I've created clone that uses Bootstrap 3.3 - http://tunguski.github.io/msb3-maven-skin (not deployed in maven central). But I found working with custom maven site generation extremely hard, especially when you compare it to tools like Jekyll. So I started a research project asking how hard would it be to create totally new theme without changing default maven site generation. I've created proof of concept visible here: http://maven.matsuo-it.com. Full source code is availible on github: https://github.com/tunguski/angular-boostrapize-maven-site. Generally it is starndard maven site data, but themed using bootstrap 3.3. It uses Angular 1.4 for data extraction (from original site), adding dynamic elements like menu generation, scroll to top etc. At this point it probably won't index in search engines at all. Goals achieved in most part: * it looks and works really well on all kinds of devices * it has themes changed in seconds - you may choose a skin and highlighting theme (upper right corner of the screen) * it creates additional menu builded from headers in page content * it unifies theme for sites created with default and fluido skin * it tries to provide fresh view on javadocs and java sources (it's far from perfect) * it adds simple search of artifacts from search.maven.org * it provides
Re: [VOTE] Release Apache Maven Verifier Plugin version 1.1
+1 On 14 April 2015 at 16:16, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, I need one more binding VOTE ? Kind regards Karl Heinz Marbaise On 4/10/15 8:07 PM, Karl Heinz Marbaise wrote: Hi, We solved 4 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa? projectId=12318120version=12331744 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project+%3D+ MVERIFIER+AND+status+%3D+Open+ORDER+BY+priority+DESC Staging repo: https://repository.apache.org/content/repositories/maven-1166 https://repository.apache.org/content/repositories/maven- 1166/org/apache/maven/plugins/maven-verifier-plugin/1.1/ maven-verifier-plugin-1.1-source-release.zip Source release checksum(s): maven-verifier-plugin-1.1-source-release.zip sha1: 68b08332b15e464b524d6c899f733c167a9ab3ab Staging site: http://maven.apache.org/plugins-archives/maven-verifier-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 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Yes net beans does support it, jesse Glick (who is a net beans fanboy...
Because he used to be a net beans developer) foisted a JDK 6 for src/main
and JDK 8 for src/test on us at work... Where we all are left cursing
IntelliJ for not supporting same
On Tuesday, April 14, 2015, Milos Kleint mkle...@gmail.com wrote:
afaik netbeans does support it (having different source/target level for
test and main source) Not from the UI, but if you have your compiler plugin
setup properly, it will take it into account.
Milos
On Sat, Apr 11, 2015 at 11:35 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com javascript:; wrote:
Technically we support main scoped sources in java6 and test
scoped sources in java7 today, but the feature is largely unusable
since IDE support is totally missing. Even IntelliJ does not support
it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues)
:(
There might be some hope of gaining some kind of traction to both
source and main-level support of multi-language-level modules. Maybe
something like (src/main/java and src/test/java = default language
level) while src/[main|test]/java-8 would be a specific language
level. This sounds infinitely cool, but also like a great can of worms
:) I assume minimum compiler requirement would be java-8 for a project
with src/main/java-8 ?
K
2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr
javascript:;:
Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
IDE support for multiple source trees seems quite far off ?
IDE support for current situation, where we mix multiple Java API
versions in
one single source tree, is even more far off!
With separate source trees, IDE support starts like we are at the
moment
= no
IDE support
but IDEs that want to do something about it have a chance: that's the
big
difference IMHO
Regards,
Hervé
Kristian
2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr
javascript:;:
Hi,
Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de
Loof
and me met Brian Goetz and discussed about the objective of JEP 238
and
what we could get from such a feature.
Having a face to face explanation in front of a white board gave
interesting ideas: then, *as library maintainer*, I tried to modifiy
plexus-utils code to use MVJAR for Java 7 enhancement that are
currently
triggerred through reflection
Here is the result [1]:
I extracted 2 little xxxMv classes containing only the few methods
that
had to be enhanced when runing on Java 7, replacing the
if (Java7Detector.isJava7()) {
// java 7
} else {
// Java 5
}
stanza with the default Java 5 code in the main src/main/java source
tree
and Java 7 reimplementation in src/main/java-7 source tree
and I did cleanup: removed Java7Detector and moved NioFiles to this
java-7
specific source tree
the result is a main src/main/java source tree that can be compiled
with
JDK 5 and a src/main/java-7 source tree that is minimal to be
compiled
with JDK 7
I still didn't try to update pom.xml to see what
maven-compiler-plugin and
maven-jar-plugin configurations could look like.
and I don't know if javac will be enhanced to do the 2 compilations
in 1
command like javac -target 1.5 src/main/java -target 1.7
src/main/java-7
or if it'l have to launch 2 javac one after the other
I didn't look at maven-jar-plugin to see if it uses jar command
that
will be enhanced to mix multiple target/classes or if it uses
JarFile
class then will need to code the mix
and I don't know if javac will have tru crossplatform compilation
option,
to avoid using 2 JDKs (ie JDK 5 for compiling java 5 code and being
sure
there is no Java 7 API reference, and JDK 7 for the java 7 part)
I see there will be impact on tooling, and if javac does a part of
the
job,
this will be a lot easier to implement at Maven level
But at the moment, my objective was not from Maven point of view but
library developper point of view: show a real world case of how an
existing library could be refactored to use the feature, expecting
that
the new source code would be easier to maintain
WDYT?
Regards,
Hervé
[1]
https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main/jav
a-7/org/codehaus/plexus/util
Le jeudi 19 mars 2015 23:38:32 Robert Scholte a écrit :
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
[RESULT] [VOTE] Release Apache Maven JavaDoc Plugin version 2.10.3
Hi, The vote has passed with the following result: +1 (binding): Hervé Boutemy, Karl Heinz Marbaise, Olivier Lamy +1 (non binding): none I will promote the artifacts to the central repo. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Arnaud, Arnaud Héritier wrote: In short/middle term the lack of IDE integration isn't a real problem for now. Like Brian said, they know that users won't use such feature before several years. The runtime part providing the compatibility for the JRE should be backported to Java 8 but only Java 9 JDK will provide required tools to create such jars. The goal to involve build tools ASAP is to validate the technical feasibility to integrate such new feature before J9 is out (and not to wait for its delivery to do it - and complain when it will be too late) You can already use several executions for the compiler plugin to create a jar file with classes targeting different JDKs. That's what XStream does for years already. yes exactly. But to be user friendly we'll have to provide something easy to setup. Not 100 lines of XML The challenge is that you have multiple class files with same name. Yes. AFAIU for now it will be several call of javac with a new option for the targeted platform 1 call of javac with java 7 for example and then a call of javac with the result of J7 build + sources for 8 + option for the J8 platform target What we need to do here is to imagine how it will be in 2/3? years when we'll start to have developers using a JDK9 who'll want to provide librairies compatible (and optimized) for previous JREs. For me (in my dreams) it should clearly be in only one module and thus probably with additional sources directories. The compiler plugin should hide (in one or several steps) the compilation of sources and the jar packaging should discover if it has to create a mvjar or not You have different use cases here. One time you have one Java source that will behave different depending against which runtime libs you have compiled (e.g. a different overloaded method is used). In another scenario your Java code actually differs. So, for Maven there might be several src folders ... or you have annotations at types, methods and/or fields indicating the target runtime. However, the result should be a jar file that allows a client to write code that is indifferent of the multiple versions of a class. Wait ... maybe the client will have to create a mvjar himself, because the different versions also result in different versions of his own code (think about JDBC api) ...? I remember about the JDBC API breakage (it was in J5 ?) but what mvjar wants to cover is that case of an api which doesn't change across implemented platforms (only the implementation itself). If the API changes this is another problem. IMHO, mvjars will create a bigger maintenance mess than the current solutions. I don't know. I think it really depends if your are provider or consumer of mvjars. If you are consumer you may imagine to not have to manually switch anymore between several implementations (using classifiers ) and it gives you the ability to do the selection at runtime and not at build time. As producer I agree that it won't be easy if tools (Build, IDE) aren't providing a good/simple support. That's why Oracle (Brian) is trying to involve us. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote: I expect we could run the unit test suite on JDK 6 / 7 / 8 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 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 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 version. more precisely: the first module would contain the source for minimum Java version: sometimes, it will contain code that won't run with later JRE This kind of slicing is necessary because you do need different kinds of compiler directives (like -source), different JREs to run unit tests differently, and most importantly, the different JREs to allow debugging according to the Java version you want to test. The other piece that doesn't yet exist is a way to bundle the modules into one jar. Perhaps this can be accomplished by introducing a new mvjar Maven type. I didn't imagine this scenario: no Maven plugins updates nor IDE, just a new feature to merge multiple modules into on MV jar interesting idea, in fact: this would seriously reduce the impact on tooling, even if the result is less compact, ie creates a lot of Maven modules and I am wondering what unit tests will look like for additional versions: the good thing is that they
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Actually this is worse. This would be Maven forcing us to create 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 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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote: I expect we could run the unit test suite on JDK 6 / 7 / 8 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 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 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 version. more precisely: the first module would contain the source for minimum Java version: sometimes, it will contain code that won't run with later JRE This kind of slicing is necessary because you do need different kinds of compiler directives (like -source), different JREs to run unit tests differently, and most importantly, the different JREs to allow debugging according to the Java version you want to test. The other piece that doesn't yet exist is a way to bundle the modules into one jar. Perhaps this can be accomplished by introducing a new mvjar Maven type. I didn't imagine this scenario: no
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
For now yes it is probably the only solution but the JCP should work with IDE teams to have this solved. I don't want to see Maven doing crappy stuffs because of IDEs There are already a lot of limitations in IDE (at least some of them) compared to Maven like the ability to have several classpaths Maven must propose something easy/clean to manage mvjars and should allow a degraded mode (perhaps with several modules) to allow to use any IDE (the time they didn't natively support it). WDYT ? On Tue, Apr 14, 2015 at 12:53 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Actually this is worse. This would be Maven forcing us to create 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 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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote: I expect we could run the unit test suite on JDK 6 / 7 / 8 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 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 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
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
Hi Arnaud, Arnaud Héritier wrote: On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de wrote: [snip] IMHO, mvjars will create a bigger maintenance mess than the current solutions. I don't know. I think it really depends if your are provider or consumer of mvjars. If you are consumer you may imagine to not have to manually switch anymore between several implementations (using classifiers ) and it gives you the ability to do the selection at runtime and not at build time. As producer I agree that it won't be easy if tools (Build, IDE) aren't providing a good/simple support. That's why Oracle (Brian) is trying to involve us. Actually my biggest fear is for such a feature that some people will find *very* creative ways to use it. Therefore I hope that mvjars will be consequently restricted e.g. they should not be allowed to provide changes in the API for different versions. Better safe than sorry. - Jörg - 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
On Tue, Apr 14, 2015 at 11:55 AM, Jörg Schaible joerg.schai...@swisspost.com wrote: Hi Arnaud, Arnaud Héritier wrote: On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de wrote: [snip] IMHO, mvjars will create a bigger maintenance mess than the current solutions. I don't know. I think it really depends if your are provider or consumer of mvjars. If you are consumer you may imagine to not have to manually switch anymore between several implementations (using classifiers ) and it gives you the ability to do the selection at runtime and not at build time. As producer I agree that it won't be easy if tools (Build, IDE) aren't providing a good/simple support. That's why Oracle (Brian) is trying to involve us. Actually my biggest fear is for such a feature that some people will find *very* creative ways to use it. Therefore I hope that mvjars will be consequently restricted e.g. they should not be allowed to provide changes in the API for different versions. Better safe than sorry. yes, totally agree. For me it should be the case. As far as I understood the compiler should allow only to override a class or a method with a more optimized code. It shouldn't allow to add something (but I don't know how they'll do. Perhaps they'll allow only new private methods/fields) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
In addition, even if IDEs were to support the MVJAR spec, that doesn't answer how Maven should natively answer the spec. Relying on IDE support isn't a good total answer, but it is a good complimentary answer. Maven just has to answer it with configuration and command line tooling too. Cheers, Paul On Tue, Apr 14, 2015 at 10:14 AM, Carlos Sanchez car...@apache.org wrote: My 0.02 The current approach to use multiple modules, poms,... is a pita and mvjar would fix that, while bringing new interesting problems such as testing the possible combinations. But that is ok. Lack of IDE support shouldn't stop us, if it is useful for maven users that may push the IDEs If the Maven user wants to use mvjar by putting sources in src/main/java8 src/main/java9 or whatever convention we decide, then the compiler, jar,... plugins should transparently handle all the necessary compilations and packaging without extra pom configuration. If they decide to stick with multimodule, they can still do that. So if we are ok with the plugins recognizing these mvjar projects then it is left for someone to implement some jira issues in the best way possible while retaining backwards 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 have done for years when needed), you're just binding things up at the end. Forget this is about the MVJAR initiative because this is just how you would solve this minus the special packaging. Cheers, Paul On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Actually this is worse. This would be Maven forcing us to create 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 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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
On Tue, Apr 14, 2015 at 10:32 AM, 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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) +1 I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote: I expect we could run the unit test suite on JDK 6 / 7 / 8 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 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 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 version. more precisely: the first module would contain the source for minimum Java version: sometimes, it will contain code that won't run with later JRE This kind of slicing is necessary because you do need different kinds of compiler directives (like -source), different JREs to run unit tests differently, and most importantly, the different JREs to allow debugging according to the Java version you want to test. The other piece that doesn't yet exist is a way to bundle the modules into one jar. Perhaps this can be accomplished by introducing a new mvjar Maven type. I didn't imagine this scenario: no Maven plugins updates nor IDE, just a new feature to merge multiple modules into on MV jar interesting idea, in fact:
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
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 have done for years when needed), you're just binding things up at the end. Forget this is about the MVJAR initiative because this is just how you would solve this minus the special packaging. Cheers, Paul On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Actually this is worse. This would be Maven forcing us to create 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 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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote: I expect we could run the unit test suite on JDK 6 / 7 / 8 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 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 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 version. more precisely: the first module would contain the source
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
My 0.02 The current approach to use multiple modules, poms,... is a pita and mvjar would fix that, while bringing new interesting problems such as testing the possible combinations. But that is ok. Lack of IDE support shouldn't stop us, if it is useful for maven users that may push the IDEs If the Maven user wants to use mvjar by putting sources in src/main/java8 src/main/java9 or whatever convention we decide, then the compiler, jar,... plugins should transparently handle all the necessary compilations and packaging without extra pom configuration. If they decide to stick with multimodule, they can still do that. So if we are ok with the plugins recognizing these mvjar projects then it is left for someone to implement some jira issues in the best way possible while retaining backwards 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 have done for years when needed), you're just binding things up at the end. Forget this is about the MVJAR initiative because this is just how you would solve this minus the special packaging. Cheers, Paul On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Actually this is worse. This would be Maven forcing us to create 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 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 project structure I had in mind: mvjar-example/ minjava/ src/main/java src/test/java java7/ src/main/java src/test/java java8/ src/main/java src/test/java The minjava and java7 and java8 are not special names (just names to denote what kind of Java source is inside). As Herve noted, minjava would contain the source minimum Java version; java7 would contain the java 7-specific sources, and java8 would contain the java 8-specific sources. like Gary answered, I think that it'll be better if we stick with java#, or j# And in this example, we'll require another module for the mvjar, that will combine result fo every other module I really hate when maven enforces us to create modules for its own technical reasons. (And I know I'm not the only one) I don't see any added difficulty with regard to testing. If you already have code that tests a specific Java X version, just extract that into its own test case file and place it in the appropriate project. At most all you're doing is minor refactoring. after thinking at it, true this module layout is definitely really clear, that's a big advantage! one thing that it makes really clear is javadoc, too, since javadoc in a mv- module is a challenge :) we should try it with plexus-utils, in another branch This will create three JARs of course (or at least today). I don't see that as a big deal since authors may decide to distribute this way where MVJAR isn't supported (like pre-Java 9 JVMs). IMHO, not really, since the minimum version module will contain absolutely every classes, but the other modules will contain only a few classes = the few code that is rewritten to take advantage of newer JDK Compatibility with old jdks that do not support mvjar is built into mvjar JEP: a JVM that does not support mvjar extension will see minimum version modules (and useless content in /META-INF/versions/) notice that every module will ave its own GAV coordinates: the last mvjar module will have the end-user coordinates, where every JDK-version-specific module will have an artifactId = artifactId-java# (that's a generic convention we should try to push forward) However, if we can bind up all the jars into one in a post-processing phrase, you can then meet the MVJAR specification. PS: I really don't know if an mvjar type is necessary. Honestly, I hope it's not. I thought it was needed in the beginning, but am not sure anymore. Opinions appreciated. I don't know if the merging will require a dedicated packaging: we'll see later now it's time to test on plexus-utils: givent this idea doesn't involve much new things in maven, I'm pretty sure we can make it full functional! I'll try to do it tonight if nobody beats me at it Regards, Hervé Cheers, Paul On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com wrote:
Re: Maven Web Site
On 14 Apr 2015, at 18:34, Olivier Lamy wrote: wow, impressive! Definitely agree!!! A third on that! That's tempting me to _actually_ use maven sites. -- 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: Maven Web Site
On 14 Apr 2015, at 18:50, Hervé BOUTEMY wrote: no secret: 1920x1200 = good screen for a desktop, Do you always run your browser full screen? I don't. -- 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
[GitHub] maven-scm pull request: SCM-706 finer-grained handling of file ren...
GitHub user sergei-ivanov opened a pull request: https://github.com/apache/maven-scm/pull/31 SCM-706 finer-grained handling of file rename status for gitexe provider... ..., rename source is not added to the set of files for commit operation anymore This is an actualisation of the original Darryl L. Miles's patch from [SCM-706](https://issues.apache.org/jira/browse/SCM-706). All tests for gitexe provider are passing locally. I've also confirmed locally that it fixes the `release-with-pom` behaviour in `maven-release-plugin` under git. You can merge this pull request into a Git repository by running: $ git pull https://github.com/sergei-ivanov/maven-scm master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-scm/pull/31.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 #31 commit 8b8db484f0d800bcfbbe35e821a8b34435e09683 Author: Sergei Ivanov sergei_iva...@mail.ru Date: 2015-04-15T00:42:35Z SCM-706 finer-grained handling of file rename status for gitexe provider, rename source is not added to the set of files for commit operation anymore --- 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
