preselected="no" pack checked in installer

[Armin M]

Hi,

I'm in the process pf porting a 4.x installer to 5.0.7. The following pack is set to preselected="no" but it still comes up as checked in the installer: (this used to work in the 4.x installer)

<pack id="jspwiki" name="JSPWiki" preselected="no" required="no">
    <description>JSPWiki (includes Apache Tomcat) - required to display an exported Wiki on a client</description>
    <file src="@{SSDE_STATIC}\apache-tomcat" targetdir="$INSTALL_PATH" />
    <parsable targetfile="$INSTALL_PATH/apache-tomcat/webapps/mywiki/WEB-INF/jspwiki.properties" type="javaprop"/>
    <singlefile override="true" src="@{installerBase}\Resources\org.eclipse.ui.prefs" target="$INSTALL_PATH/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.prefs"/>
    <parsable targetfile="$INSTALL_PATH/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.prefs" type="javaprop" />
</pack>

Any ideas?

Thanks,
Armin

[René Krell]

HI Armin,

I cannot reproduce this in a simple test installer compiled in 5.0.7 (and also not in 5.0.8-SNAPSHOT).

The pack is shown unselected given the combination preselected="no" required="no".

Can you review this, please? 

René

Dne pondělí 21. března 2016 18:43:26 UTC+1 Armin M napsal(a):

[René Krell]

Just another note, the pack is shown preselected by default in case the attribute preselected is not there at all. In case it exists the value "no" works for me as expected, as I mentioned before.

Dne pondělí 21. března 2016 23:52:56 UTC+1 René Krell napsal(a):

[Armin]

2016-03-21 23:58 GMT+01:00 René Krell <renda...@gmail.com>:

Just another note, the pack is shown preselected by default in case the attribute preselected is not there at all. In case it exists the value "no" works for me as expected, as I mentioned before.

not for me :-( I just added another dummy pack, also with preselected="no", it shows up in the installer and is checked. Next I created a small test installer with two packs, one preselected="yes" required="yes", the other preselected="no" required="no" - still both show up checked in the generated installer.

Should I put the test installer files somewhere? I suppose there is either some side effect from some other setting which is causing this or it's my environment Java(TM) SE Runtime Environment (build 1.8.0_72-b15) (32 bit) on a Win7/64. I did notice that IzPack installed into C:\Program Files (i.e. the location for 64 bit software - could that be a reason...?)

 

[René Krell]

2016-03-22 9:33 GMT+01:00 Armin <arm...@gmail.com>:

2016-03-21 23:58 GMT+01:00 René Krell <renda...@gmail.com>:

Just another note, the pack is shown preselected by default in case the attribute preselected is not there at all. In case it exists the value "no" works for me as expected, as I mentioned before.

not for me :-( I just added another dummy pack, also with preselected="no", it shows up in the installer and is checked. Next I created a small test installer with two packs, one preselected="yes" required="yes", the other preselected="no" required="no" - still both show up checked in the generated installer.

Should I put the test installer files somewhere?

Yes, please. Best would be a ZIP with a simple, but complete compilable installer including example files to be packed, even better with POM or with command line hint how you compile it.

 

I suppose there is either some side effect from some other setting which is causing this or it's my environment Java(TM) SE Runtime Environment (build 1.8.0_72-b15) (32 bit) on a Win7/64. I did notice that IzPack installed into C:\Program Files (i.e. the location for 64 bit software - could that be a reason...?)

 

I can hardly imagine this to be the reason.

[Andreas Kuhtz]

Hello,

I can confirm that this does not work under Windows :-(

<pack id="optional" name="@{projectname} optional" preselected="no" required="no">   <description>Optional pack</description>
</pack>

This pack is shown as selected initally and the checkbox is grayed initially. However when I click in the check box it's enabled and the check is removed.

After that the checkbox is rendered correct.

Regards,

Andreas

--
You received this message because you are subscribed to the Google Groups "izpack-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to izpack-user...@googlegroups.com.
To post to this group, send email to izpac...@googlegroups.com.
Visit this group at https://groups.google.com/group/izpack-user.
For more options, visit https://groups.google.com/d/optout.

[René Krell]

Hi Andreas,

you're also in 5.0.7 or in master? There has been a change recently in master in PacksModel.

René

[Andreas Kuhtz]

Hi René,

Fails with 5.0.7 but works with 5.0.8-SNAPSHOT!

Regards,

Andreas

[René Krell]

Oh, good news.

@Armin: You can send the example installer but even better would be if you'd try this against the lastest izpack/master branch or the deployed snapshot 5.0.8-SNAPSHOT, if you are able to do this. Maybe this will take you less time than assembling an example for reproducing.

René

[Armin]

2016-03-22 10:42 GMT+01:00 René Krell <renda...@gmail.com>:

Oh, good news.

@Armin: You can send the example installer but even better would be if you'd try this against the lastest izpack/master branch or the deployed snapshot 5.0.8-SNAPSHOT, if you are able to do this. Maybe this will take you less time than assembling an example for reproducing.

I'm not in a hurry since I still use 4.x for the production builds. What's the easiest way to get to the current 5.0.8 snapshot?

[Andreas Kuhtz]

Hi,

Configure http://oss.sonatype.org/content/repositories/snapshots/ as maven repo for plugins ...

Regards,

Andreas

--

[René Krell]

If you compile in Maven just change the version of the izpack-maven-plugin, of course.

You just need to add the Sonatype OSS Snapshots (https://oss.sonatype.org/content/repositories/snapshots) repository to your %M2_HOME%/settings.xml.

Example:

<repositories>

    ...

        <pluginRepository>

          <id>sonatype-oss-snapshots</id>

          <url>https://oss.sonatype.org/content/repositories/snapshots/</url>

          <releases>

            <enabled>false</enabled>

          </releases>

          <snapshots>

            <enabled>true</enabled>

          </snapshots>

        </pluginRepository>

<repositories>

Otherwise IzPack snapshots are deployed here: located https://oss.sonatype.org/content/repositories/snapshots/org/codehaus/izpack/, if you want to download and/or install something manually.

--

[Armin]

2016-03-22 10:55 GMT+01:00 René Krell <renda...@gmail.com>:

Otherwise IzPack snapshots are deployed here: located https://oss.sonatype.org/content/repositories/snapshots/org/codehaus/izpack/, if you want to download and/or install something manually.

I just tested with https://oss.sonatype.org/content/repositories/snapshots/org/codehaus/izpack/izpack-dist/5.0.8-SNAPSHOT/izpack-dist-5.0.8-20160317.205205-3.jar - with that build, I get the following exception when trying to run my generated installer:

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/io/IOUtils
        at com.izforge.izpack.core.resource.AbstractResources.getObject(AbstractResources.java:189)
        at com.izforge.izpack.core.resource.DefaultLocales.getSupportedLocales(DefaultLocales.java:439)
        at com.izforge.izpack.core.resource.DefaultLocales.<init>(DefaultLocales.java:117)
        at com.izforge.izpack.core.resource.DefaultLocales.<init>(DefaultLocales.java:103)
        at com.izforge.izpack.installer.container.provider.LocalesProvider.provide(LocalesProvider.java:40)
...

(didn't get this with 5.0.7 obviously) And we don't use Maven for our builds...

[Andreas Kuhtz]

Hello,

Add commons-io-2.4.jar to your classpath. I don't know which build tool you use but google is your friend :-)

Regards,

Andreas

--

[Armin]

Add commons-io-2.4.jar to your classpath. I don't know which build tool you use but google is your friend :-)

I'm calling izpack via ant and there was never any need to modify the classpath... (so far, I simply installed the izpack-dist jars)

[René Krell]

This shouldn't happen, commons-io should be merged completely to installer automatically. Strange, another thing I can't see in my installers, even not the localized, but I build with Maven.

I suspect the build.xml misses commons-io.jar and the compiler doesn't complain if the classes to be merged can't be found.

2016-03-22 12:21 GMT+01:00 Armin <arm...@gmail.com>:

Add commons-io-2.4.jar to your classpath. I don't know which build tool you use but google is your friend :-)

I'm calling izpack via ant and there was never any need to modify the classpath... (so far, I simply installed the izpack-dist jars)

--

[René Krell]

@Armin: Can you please provide exactly how you build this (maybe beginning from the installation of using izpack-dist.jar), including the command line/script, whatever you use.

I don't usually use Ant builds, we should add an automatic test for it, possibly.

Dne úterý 22. března 2016 12:21:11 UTC+1 Armin M napsal(a):

[Armin]

2016-03-22 12:22 GMT+01:00 René Krell <renda...@gmail.com>:

This shouldn't happen, commons-io should be merged completely to installer automatically. Strange, another thing I can't see in my installers, even not the localized, but I build with Maven.

I suspect the build.xml misses commons-io.jar and the compiler doesn't complain if the classes to be merged can't be found.

Just to clarify: Our actual software build is kind of complex (Buckminster & Eclipse PDE via ANT...) and was never ported to Maven. Hence I build our product installer completely independent from the actual software build, basically with an ant -f izpack_build_50.xml our_package command from a batch file.

This produces a runnable installer with 5.0.7 (but with the packs checked issue) and it produces an installer which throws the above exception with the current snapshot.

[Armin]

Here's the abbreviated izpack_build_50.xml file:

<project name="ssde_installer" default="ssde_package">
    <property environment="ENV" />
    <property name="SSDE_STATIC" value="${ENV.SSDE_STATIC}" />
    <!-- ... -->

    <path id="build.classpath">
        <fileset dir="C:/Program Files/IzPack">
            <include name="lib/*.jar" />
        </fileset>
    </path>
        
    <taskdef name="IzPack" classpathref="build.classpath" classname="com.izforge.izpack.ant.IzPackTask" />

    <target name="ssde_package">
        <echo message="Running IzPack to build the installer..."/>
        <IzPack input="SSDEInstaller50.xml"
            output="${SSDE_REL_DIR}/SSDEInstaller_${ENV.SSDE_VERSION}.jar"
            installerType="standard"
            inheritAll="true"
            basedir="${ENV.INSTALLER_BASE}"/>
        <echo message="Done."/>
    </target>

</project>

 

--
You received this message because you are subscribed to a topic in the Google Groups "izpack-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/izpack-user/3aWI2QN2tXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to izpack-user...@googlegroups.com.

[René Krell]

I understand, there has been completely integrated commons-io.jar in 5.0.8-SNAPSHOT, which replaces a lot of functionality we had in our own utility classes (and there will be more, to no longer reinvent the wheel).

The question is where is the interface between your scripts, build files etc. to the Ant build provided by IzPack.

We need somehow to extract and simplify it to simulate this problem and not to loose too much time with this one issue.

Dne úterý 22. března 2016 12:27:17 UTC+1 Armin M napsal(a):

[Armin]

2016-03-22 12:32 GMT+01:00 René Krell <renda...@gmail.com>:

The question is where is the interface between your scripts, build files etc. to the Ant build provided by IzPack.

I'm not sure I understand the question... With 5.0.7 I have
* downloaded and installed https://oss.sonatype.org/content/repositories/releases/org/codehaus/izpack/izpack-dist/5.0.7/izpack-dist-5.0.7.jar
* at that point, our own software has already been fully built and exported, no interface to IzPack there whatsoever

* then, I produce our installer as shown above by calling ant -f izpack_build_50.xml ssde_package (from some script but for the sake of simplicity I could do this from the commandline, too)

So the "interface" is simply the above ant call. 5.0.7 produces an installer which starts, 5.0.8.snapshot has the dependency issue

[René Krell]

The "interface" seems to be in izpack_build_50.xml.

--

[Armin]

Do you need IzPack input="SSDEInstaller50.xml" ?

--
You received this message because you are subscribed to a topic in the Google Groups "izpack-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/izpack-user/3aWI2QN2tXo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to izpack-user...@googlegroups.com.

[Andreas Kuhtz]

I just tested your build.xml with my installer.xml and it works (with izpack installed under C:\Program Files\izpack and added this directory to %PATH%).

[Armin M]

jar tvf TestInstaller.jar |grep commons
 11769 Tue Jun 12 18:18:26 CEST 2012 org/apache/commons/io/FilenameUtils.class

That's all there is of commons in the generated installer

[René Krell]

I still don't get assembled the build of your kind.

But it seems you don't have the current version of izpack-compiler.jar in the build classpath. For whatever reason.

In particular, packing all of commons-io is done in com.izforge.izpack.compiler.packager.impl.PackagerBase#writeSkeletonInstaller

This class got the relevant changes in two commits:

8d698d5 3/8/16 5:39 PMRené Krell IZPACK-1376: Using AntActionInstallerListener forces to add commons-io.jar explicitly - basic fix

fcaaedc	3/10/16 12:03 PM	René Krell	IZPACK-1376: Using AntActionInstallerListener forces to add commons-io.jar explicitly:...

Dne úterý 22. března 2016 14:43:10 UTC+1 Armin M napsal(a):

[Armin M]

I still don't get assembled the build of your kind.

But it seems you don't have the current version of izpack-compiler.jar in the build classpath. For whatever reason.

Apparently this was some leftover of 5.0.7 - I had installed 5.0.8.snapshot w/o deinstalling 5.0.7 first. Doing that and reinstalling 5.0.8.snapshot now produces an installer which works and which also shows the preselected="no" packs unchecked :-)

[René Krell]

Even better news :-)

So everything is fine now? That's what we want :-)

Better to say everything will be fine as soon as 5.0.8 gets released. We're still testing things and the snapshot gets always to become mature some days or weeks...

Dne úterý 22. března 2016 15:54:46 UTC+1 Armin M napsal(a):

[Armin]

2016-03-22 16:34 GMT+01:00 René Krell <renda...@gmail.com>:

Even better news :-)

So everything is fine now? That's what we want :-)

In regards to the checked pack - yes - will still need to test some other aspects of the ported installer scripts
 

Better to say everything will be fine as soon as 5.0.8 gets released. We're still testing things and the snapshot gets always to become mature some days or weeks...

Our next release is sometime in summer, enough time to wait for 5.0.8 final :-)

Thanks for the help so far!

[René Krell]

I found the reason for this.

In our dist installer we rely on the default value of the override attribute for installing files in packs:

        <pack name="Core" required="yes">

            <fileset dir="" targetdir="$INSTALL_PATH">

                <include name="README.md"/>

                <include name="LICENSE"/>

                <include name="KEYS"/>

                <include name="NOTICE"/>

                <include name="bin/**"/>

                <include name="lib/**"/>

                <include name="legal/**"/>

                <include name="schema/**"/>

            </fileset>

            ...

        </pack>

This is wrong, but the default should be at least "update" (ovwrwrite newer files). But even this probably doesn't happen, because beginning from 5.0.7, in case of not using an attribute, but this attribute is defined in the XSD with a default value, default value from the XSD is used, which is also wrong and does not match the compiler implementation for all three tags, fileset, file and singlefile:

<xs:attribute name="override" type="overrideType" use="optional" default="false"/>

Hence, Achim, thumbs up, I believe this is an obvious bug you figured out this way!

On updates of izpack-dist existing files must be overwritten.

I created an issue describing this: https://izpack.atlassian.net/browse/IZPACK-1385

René