I’m still using 8.2 in production, and I’ve never seen it replace the version.
However, i use the following recommended strategy in maven projects.
1. Use variables for storing versions used in dependencies
2. Use the versions [1] plugin to identify new releases
3. Never use ranges, it’s not
I'm frequently annoyed by this too. Has a bug been filed?
-Tim
--
http://timboudreau.com
Am Freitag, den 27.07.2018, 23:41 +0200 schrieb Geertjan Wielenga:
> Or maybe, thanks to the changes in that PR, the current issue
> reported by
Please don't jump to conclusions. The issues are not identical and the
changeset is not the cause of the new bug.
Before the referenced changeset an
Or maybe, thanks to the changes in that PR, the current issue reported by
Ken occurs.
Gj
On Fri, Jul 27, 2018 at 11:39 PM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:
> That's exactly the same problem that Ken describes, thanks a lot for
> identifying this.
>
> Gj
>
> On Fri,
That's exactly the same problem that Ken describes, thanks a lot for
identifying this.
Gj
On Fri, Jul 27, 2018 at 11:36 PM, Matthias Bläsing <
mblaes...@doppel-helix.eu> wrote:
> Hi Gj,
>
> Am Freitag, den 27.07.2018, 23:30 +0200 schrieb Geertjan Wielenga:
> > Absolutely, I'm not disagreeing
Hi Gj,
Am Freitag, den 27.07.2018, 23:30 +0200 schrieb Geertjan Wielenga:
> Absolutely, I'm not disagreeing with you at all, in fact it's 24.00 here
> and I am trying to identify where the problem is coming from.
a similar problem (corruption of XML structure)
You could use ranges (available maven and Gradle) and teach maven
coordinate concepta and semcer.org While I realize this may not address
using the IDE the way you want, it may help address the software
engineering issue raised.
On Fri, Jul 27, 2018, 16:51 Kenneth Fogel
wrote:
> What I like
Absolutely, I'm not disagreeing with you at all, in fact it's 24.00 here
and I am trying to identify where the problem is coming from.
Gj
On Fri, Jul 27, 2018 at 11:29 PM, Kenneth Fogel
wrote:
> I absolutely do not consider this an issue that should hold up the
> release. However, it is in my
I absolutely do not consider this an issue that should hold up the release.
However, it is in my opinion a bug that needs to be addressed. A feature of
NetBeans has been diminished and needs to be addressed at least for 9.01.
Ken
-Original Message-
From: Geertjan Wielenga
Sent: July
Maybe you can tell students to first select the whole number and then call
up code completion. Then code completion will replace that whole selected
number with whatever is selected from the code completion box.
Gj
On Fri, Jul 27, 2018 at 11:03 PM, Geertjan Wielenga <
Well, no one has touched the Maven modules AFAIK. I can reproduce it
though. I'm sure you're aware that we've now voted on the release and we're
pretty close to releasing it, so it's certainly not going to be fixed in
time for 9.0 at this stage. Not sure how it's going to be worked out to fix
What I like about 8.2 was that I could explore all the possible versions and
either stay with the one I have or switch to a newer or older one. Deleting
what's there first shouldn’t be necessary. From a teaching perspective, what
will happen is that students will be inserting new version
Maybe delete the number that you don't want and then call up code
completion?
Gj
On Fri, Jul 27, 2018 at 9:55 PM, Kenneth Fogel
wrote:
> I have just added this to jira but I'm curious if anyone else noticed this
> in 9.0 vc3.
>
> When editing the pom.xml file:
> 1.5 in any place in a pom.xml.
I have just added this to jira but I'm curious if anyone else noticed this in
9.0 vc3.
When editing the pom.xml file:
1.5 in any place in a pom.xml.
Type a period in front of the existing period and I get a list of other version
numbers.
When I select the new version it is inserted into the
14 matches
Mail list logo
