I think a preference for the default tool would make sense. Or even if it just
remembered your last selection so you don’t have to keep changing it. The
initial default should be Maven at this point, but maybe it could be Gradle if
it ever becomes a first class citizen.
I also agree with
On Sat, 24 Nov 2018 17:02:02 +0100, Martin Desruisseaux
wrote:
Le 24/11/2018 à 16:39, Robert Scholte a écrit :
**If And Only If** you want to make use of single tool invocation for
all you JPMS modules, then you cannot use Maven, it's architecture
doesn't support it and any plugin trying
Le 24/11/2018 à 16:39, Robert Scholte a écrit :
> **If And Only If** you want to make use of single tool invocation for
> all you JPMS modules, then you cannot use Maven, it's architecture
> doesn't support it and any plugin trying to solve this is a hack.
>
But isn't what you are going to do for
Sounds good to me. I would also suggest that the Gradle plugin should be
part of the base IDE.
I don't thin Maven in classroom is an issue. In ANT they need to download
dependencies as well. In those cases they can install locally from the
provided ones.
On Sat, Nov 24, 2018, 9:44 AM Robert
On Sat, 24 Nov 2018 15:34:51 +0100, Martin Desruisseaux
wrote:
Le 24/11/2018 à 15:10, Robert Scholte a écrit :
Today I started looking at MJAVADOC-449 again and it seems that just
nobody took serious time to solve this. I've been able to create the
proper commandline by moving some
Le 24/11/2018 à 15:10, Robert Scholte a écrit :
> Today I started looking at MJAVADOC-449 again and it seems that just
> nobody took serious time to solve this. I've been able to create the
> proper commandline by moving some classpath entries to the modulepath.
> Now it is a matter of
On Sat, 24 Nov 2018 15:02:08 +0100, Martin Desruisseaux
wrote:
Le 24/11/2018 à 13:53, Robert Scholte a écrit :
With the Java Platform Modular System you'll clearly see different
requirements between library and application developers.
Indeed (e.g. jlink is for application developers),
Le 24/11/2018 à 13:53, Robert Scholte a écrit :
> With the Java Platform Modular System you'll clearly see different
> requirements between library and application developers.
>
Indeed (e.g. jlink is for application developers), but the requirements
I'm talking about are for library developers.
Le 24/11/2018 à 13:28, Martin Desruisseaux a écrit :
> The key part is "--module-path".
Sorry I mean "--module-source-path" for the compilation and javadoc
generation parts. Likewise I mean "--source-path" instead of
"--classpath" for compilation with pre-jigsaw options.
Martin
On Sat, 24 Nov 2018 13:28:28 +0100, Martin Desruisseaux
wrote:
Hello Robert
Thanks for your reply.
Le 24/11/2018 à 12:36, Robert Scholte a écrit :
Let me correct this part: there is *no* need to change the folder
structure to work with the Java Platform Modular System. The only
thing you
Hello Jan
Le 24/11/2018 à 12:12, Jan Lahoda a écrit :
> FWIW, there is StandardJavaFileManager.setLocationForModule:
>
Hello Enrico
Le 24/11/2018 à 12:13, Enrico Olivelli a écrit :
> Have you already shared your thoughts and needs with Apache Maven group ?
>
Yes, on the mailing list. My feeling is that in order to be convincing,
I need to create a prototype showing the feasibility of my proposal.
This is the
Hello Robert
Thanks for your reply.
Le 24/11/2018 à 12:36, Robert Scholte a écrit :
> Let me correct this part: there is *no* need to change the folder
> structure to work with the Java Platform Modular System. The only
> thing you need to do is add a module-info.java to src/main/java and
>
On Sat, 24 Nov 2018 11:29:11 +0100, Martin Desruisseaux
wrote:
I think differently. In Apache SIS for example, we maintain both a Maven
and Ant project. The root source code directory is a classical Maven
project with pom.xml file [1], but we also maintain a sub-directory with
NetBeans Ant
+1 I like this idea of making Maven the default.
I'd also like to see if we could being Gradle support into the IDE by
default as well. I know its worked on as a plugin but I think bringing it
into the standard distribution would be a nice plus to have in the IDE as
well.
Regards
John
On Sat,
Martin,
Il sab 24 nov 2018, 11:29 Martin Desruisseaux <
martin.desruisse...@geomatys.com> ha scritto:
> I think differently. In Apache SIS for example, we maintain both a Maven
> and Ant project. The root source code directory is a classical Maven
> project with pom.xml file [1], but we also
Hi Martin,
I appreciate that your are using NetBeans - thanks for that!
But, as I understand Jarsolav's proposal, it only proposes to change the
presentation in the "New Project" dialog, so that the (more standard) Maven
projects would be ordered in front of/above the Ant projects. Users would
Hi all,
I fuly agree, Ant projects are dead for me. I only use NB Maven projects since
several years now and even if in the beginning the transition was not always
easy when it came to customs builds, now you can do everything you need with
Maven projects as you could with Ant AFAIK.
However,
Great idea.
On Sat, Nov 24, 2018, 11:53 AM Jaroslav Tulach Hi guys,
> the Apache NetBeans release 10 is (almost) finished and ready for
> download.
> Time to look forward: Long live Apache NetBeans - the UI for Apache Maven!
>
> NetBeans is known for its excellent Maven support. Time to bring it
I think differently. In Apache SIS for example, we maintain both a Maven
and Ant project. The root source code directory is a classical Maven
project with pom.xml file [1], but we also maintain a sub-directory with
NetBeans Ant project configuration [2]. The official project
configuration is the
20 matches
Mail list logo
