[
https://issues.apache.org/jira/browse/NETBEANS-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Miksik updated NETBEANS-1097:
----------------------------------
Description:
Steps to reproduce:
# File -> New Project -> Java Application -> Next -> Finish
# Right-click Libraries, Add JAR/Folder. Add whatever jar file.
# Check that project Properties -> Packaging -> Copy Dependent Libraries is
checked.
# Clean and Build project.
# Observe contents of dist\ directory.
When Project -> Properties -> Source/Binary Format is JDK 8, there exists
dist\lib\ directory, and the jar added in step 1) is copied into that
directory, as expected, when Copy Dependent Libraries is checked.
But when Source/Binary Format is greater than JDK 8, dist\lib\ directory does
not exist.
The reason seems to be these parts in build-impl.xml:
{code:java}
<target name="-init-modules-supported">
<condition property="modules.supported.internal" value="true">
<not>
<matches pattern="1\.[0-8](\..*)?" string="${javac.source}"/>
</not>
</condition>
</target>
...
<condition property="do.mkdist">
<and>
<isset property="do.archive"/>
<isset property="libs.CopyLibs.classpath"/>
<not>
<istrue value="${mkdist.disabled}"/>
</not>
<not>
<istrue value="${modules.supported.internal}"/> <-- WHY THIS
CONDITION??
</not>
</and>
</condition>{code}
I've observed that mkdist.disabled setting is "Copy Dependent Libraries"
checbox state negated. And do.mkdist controls the library copying.
But why is this library copying connected to javac.source version in this way?
If by design, what should I do in order to get jars copied to dist\lib\ as they
used to?
For now, a workaround seems to be manually deleting the weird
{code:java}
<not>
<istrue value="${modules.supported.internal}"/>
</not>{code}
part from build-impl.xml, but that needs to be re-done every time NetBeans
recreates it.
was:
Steps to reproduce:
# File -> New Project -> Java Application -> Next -> Finish
# Right-click Libraries, Add JAR/Folder. Add whatever jar file.
# Check that project Properties -> Packaging -> Copy Dependent Libraries is
checked.
# Clean and Build project.
# Observe contents of dist\ directory.
When Project -> Properties -> Source/Binary Format is JDK 8, there exists
dist\lib\ directory, and the jar added in step 1) is copied into that
directory, as expected, when Copy Dependent Libraries is checked.
But when Source/Binary Format is JDK 9 or JDK 10, dist\lib\ directory does not
exist.
The reason seems to be these parts in build-impl.xml:
{code:java}
<target name="-init-modules-supported">
<condition property="modules.supported.internal" value="true">
<not>
<matches pattern="1\.[0-8](\..*)?" string="${javac.source}"/>
</not>
</condition>
</target>
...
<condition property="do.mkdist">
<and>
<isset property="do.archive"/>
<isset property="libs.CopyLibs.classpath"/>
<not>
<istrue value="${mkdist.disabled}"/>
</not>
<not>
<istrue value="${modules.supported.internal}"/> <-- WHY THIS
CONDITION??
</not>
</and>
</condition>{code}
I've observed that mkdist.disabled setting is "Copy Dependent Libraries"
checbox state negated. And do.mkdist controls the library copying.
But why is this library copying connected to javac.source version in this way?
If by design, what should I do in order to get jars copied to dist\lib\ as they
used to?
For now, a workaround seems to be manually deleting the weird
{code:java}
<not>
<istrue value="${modules.supported.internal}"/>
</not>{code}
part from build-impl.xml, but that needs to be re-done every time NetBeans
recreates it.
> "Copy Dependent Libraries" does not work if "Source/Binary Format" is greater
> than JDK 8
> ----------------------------------------------------------------------------------------
>
> Key: NETBEANS-1097
> URL: https://issues.apache.org/jira/browse/NETBEANS-1097
> Project: NetBeans
> Issue Type: Bug
> Components: java - Project
> Affects Versions: 9.0, 10.0, 11.0, 11.1
> Reporter: Joonas Pulakka
> Priority: Major
>
> Steps to reproduce:
> # File -> New Project -> Java Application -> Next -> Finish
> # Right-click Libraries, Add JAR/Folder. Add whatever jar file.
> # Check that project Properties -> Packaging -> Copy Dependent Libraries is
> checked.
> # Clean and Build project.
> # Observe contents of dist\ directory.
> When Project -> Properties -> Source/Binary Format is JDK 8, there exists
> dist\lib\ directory, and the jar added in step 1) is copied into that
> directory, as expected, when Copy Dependent Libraries is checked.
> But when Source/Binary Format is greater than JDK 8, dist\lib\ directory does
> not exist.
> The reason seems to be these parts in build-impl.xml:
> {code:java}
> <target name="-init-modules-supported">
> <condition property="modules.supported.internal" value="true">
> <not>
> <matches pattern="1\.[0-8](\..*)?" string="${javac.source}"/>
> </not>
> </condition>
> </target>
> ...
> <condition property="do.mkdist">
> <and>
> <isset property="do.archive"/>
> <isset property="libs.CopyLibs.classpath"/>
> <not>
> <istrue value="${mkdist.disabled}"/>
> </not>
> <not>
> <istrue value="${modules.supported.internal}"/> <-- WHY THIS
> CONDITION??
> </not>
> </and>
> </condition>{code}
> I've observed that mkdist.disabled setting is "Copy Dependent Libraries"
> checbox state negated. And do.mkdist controls the library copying.
> But why is this library copying connected to javac.source version in this
> way? If by design, what should I do in order to get jars copied to dist\lib\
> as they used to?
> For now, a workaround seems to be manually deleting the weird
> {code:java}
> <not>
> <istrue value="${modules.supported.internal}"/>
> </not>{code}
> part from build-impl.xml, but that needs to be re-done every time NetBeans
> recreates it.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
