The Android Maven Plugin team is pleased to announce the release of version
4.2.0 of the plugin:
com.simpligility.maven.plugins
android-maven-plugin
4.2.0
true
New features/bug fixes for the specific release are
- New default value to include internal jars from aar libraries by defaul
I thought the multi-versioned JAR had a different ambition, namely
delta-snapshots.
I guess that only a fragment of classes should be deployed in muti-version
JAR due to we have already deployed previous timestamp and thus current
snapshot is only aggregated from previous JARs.
In this case the bui
Here is what Brian gave to us :
{quote}
I’ve attached the (unreviewed) patch that is slated for Java 8 — this is
the runtime-only, with no dev tools support (e.g., jar, jar signer,
compiler.) So it will let you RUN with an mvjar. I can send you the 9
patch as well if you like. Usual disclaimer
Clearly Brian told us that the goal was only to cover the needs at the core
JRE level.
They don't want (at least now) to offer such feature for something else.
I think it is really a change of mindset compared to few years ago when
they wanted to build a solution that may cover many many needs.
Now
As discussed with Brian Goetz, in the JCP/JEP side, AFAIU, the build tool
(javac with platform target option to build only a part of a class) will be
only J9+. It won't be a frankenstein build (in their mind) mixing parts
built with several JDKs.
I totally agree about the risk to use wrong APIs (It
I suspect that in the case of mvjars you will need to compile with J9 and
it will give you an option to down compile or J8.
It would not go lower than J8 as J7 is EOL in 2 weeks so they need only
support J8+ and when running on J8 an mvjar need only ignore all the stuff
in META-INF, IOW the only J
WRT compiling: no, you should always try to compile with the target JDK.
My classic example:
Suppose you have the following method in your code:
public void check( String breathSpray )
{
if ( breathSpray.isEmpty() )
{
System.out.println( "Go to Quiki Mart" );
To compile classes for a mvjar I understand that we'll need only the most
recent version (J9+) and with the right options (perhaps in several calls)
it will do the job.
For tests (multi modules or several executions in one module) if you really
want to test your code in a real situation you'll need
I like this skin as well.
Regarding QDox, the new architecture of 2.0 allows custom Model writers,
so it shouldn't be too hard to make a json output.
thanks,
Robert
Op Wed, 15 Apr 2015 16:14:07 +0200 schreef Marek Romanowski
:
2015-04-14 8:11 GMT+02:00 Hervé BOUTEMY :
wow, impressive!
I see comparison with an EAR, but instead of bundling artifacts, you could
unpack certain dependencies to the META-INF/java/x folder.
What I like about this solution that it is very clear which compiler
version is used. Even if we are able to put all sources into 1
MavenProject, it is still b
Le mardi 14 avril 2015 08:11:19 Hervé BOUTEMY a écrit :
[...]
> 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 witho
Le mardi 14 avril 2015 17:15:50 Olivier Lamy a écrit :
> On 14 April 2015 at 16:50, Hervé BOUTEMY wrote:
> > Le mardi 14 avril 2015 16:34:18 Olivier Lamy a écrit :
> > > On 14 April 2015 at 16:11, Hervé BOUTEMY wrote:
> > > > wow, impressive!
> > >
> > > Definitely agree!!!
> > >
> > > > what I
2015-04-14 8:11 GMT+02:00 Hervé BOUTEMY :
> wow, impressive!
>
Thank you! I wasn't sure is it ok to post this message here...
>
> 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've added
13 matches
Mail list logo
