Discussion:
Cannot find valid 'platform*' folder!
arittner
2012-09-12 12:34:11 UTC
Permalink
Hi!

I've switched to NetBeans 7.2 IDE and I build (with maven) RELEASE71 platform projects.

I've currently a start up error with a NetBeans Platform Maven project. It's looks like this error: http://forums.netbeans.org/topic20022.html but only with my 64Bit starter. The 32Bit starter works for me.

But the nbm:run-platform runs only the 64Bit version.

The execution line is:

cmd.exe /X /C "C:\entw\Work\svn\4.2\apps\s3standard\target\s3\bin\s364.exe --console suppress --userdir C:\entw\Work\svn\4.2\apps\s3standard\target\userdir -J-Dnetbeans.logger.console=true -J-ea --branding s3 --jdkhome C:\entw\JDK\1.7.0_04"

I get the error message: Cannot find valid 'platform*' folder!

If I start the s364.exe from the explorer I get the same error.

If I start the s3.exe with the explorer, the application starts up. No problems.

A piece of my pom.xml:


Code:

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<configuration>
<brandingToken>${brandingToken}</brandingToken>
<distributionUrl>http://www.sepix.de/updates/4.2/</distributionUrl>
<etcConfFile>config/s3.conf</etcConfFile>
<installerOsLinux>false</installerOsLinux>
<installerOsMacosx>false</installerOsMacosx>
<installerOsSolaris>false</installerOsSolaris>
</configuration>
</plugin>
</plugins>
</build>

<profiles>
<profile>
<id>deployment</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<executions>
<execution>
<id>updatesite</id>
<phase>package</phase>
<goals>
<goal>autoupdate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<properties>
<netbeans.run.params.ide/>
<netbeans.run.params>${netbeans.run.params.ide}</netbeans.run.params>
</properties>




My s3.conf:


Code:


# ${HOME} will be replaced by user home directory according to platform
default_userdir="${HOME}/.${APPNAME}/dev"
default_mac_userdir="${HOME}/Library/Application Support/${APPNAME}/dev"

# options used by the launcher by default, can be overridden by explicit
# command line switches
default_options="--branding s3 -J-Xms24m -J-Xmx512m -J-Dsun.awt.disableMixing=true"
# for development purposes you may wish to append: -J-Dnetbeans.logger.console=true -J-ea

# default location of JDK/JRE, can be overridden by using --jdkhome <dir> switch
#jdkhome="/path/to/jdk"

# clusters' paths separated by path.separator (semicolon on Windows, colon on Unices)
#extra_clusters=




How can I change (for a workaround) to the 32Bit starter "s3.exe"? What is the problem with the 64Bit starter?

best regards,
josh.
Hermien Pellissier
2012-09-12 12:38:50 UTC
Permalink
Hi,

Which version of nbm-maven-plugin are you using? This is a known issue if
you run a RELEASE71 project with version 3.8 of the nbm-maven-plugin.

The easiest workaround is to explicitly use version 3.7 of
the nbm-maven-plugin instead.

Best wishes,
Hermien PELLISSIER
Post by arittner
Hi!
I've switched to NetBeans 7.2 IDE and I build (with maven) RELEASE71 platform projects.
I've currently a start up error with a NetBeans Platform Maven project.
It's looks like this error: http://forums.netbeans.org/topic20022.htmlbut only with my 64Bit starter. The 32Bit starter works for me.
But the nbm:run-platform runs only the 64Bit version.
cmd.exe /X /C "C:\entw\Work\svn\4.2\apps\s3standard\target\s3\bin\s364.exe
--console suppress --userdir
C:\entw\Work\svn\4.2\apps\s3standard\target\userdir
-J-Dnetbeans.logger.console=true -J-ea --branding s3 --jdkhome
C:\entw\JDK\1.7.0_04"
I get the error message: Cannot find valid 'platform*' folder!
If I start the s364.exe from the explorer I get the same error.
If I start the s3.exe with the explorer, the application starts up. No problems.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<configuration>
<brandingToken>${brandingToken}</brandingToken>
<distributionUrl>http://www.sepix.de/updates/4.2/
</distributionUrl>
<etcConfFile>config/s3.conf</etcConfFile>
<installerOsLinux>false</installerOsLinux>
<installerOsMacosx>false</installerOsMacosx>
<installerOsSolaris>false</installerOsSolaris>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>deployment</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<executions>
<execution>
<id>updatesite</id>
<phase>package</phase>
<goals>
<goal>autoupdate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<properties>
<netbeans.run.params.ide/>
<netbeans.run.params>${netbeans.run.params.ide}</netbeans.run.params>
</properties>
# ${HOME} will be replaced by user home directory according to platform
default_userdir="${HOME}/.${APPNAME}/dev"
default_mac_userdir="${HOME}/Library/Application Support/${APPNAME}/dev"
# options used by the launcher by default, can be overridden by explicit
# command line switches
default_options="--branding s3 -J-Xms24m -J-Xmx512m
-J-Dsun.awt.disableMixing=true"
-J-Dnetbeans.logger.console=true -J-ea
# default location of JDK/JRE, can be overridden by using --jdkhome <dir> switch
#jdkhome="/path/to/jdk"
# clusters' paths separated by path.separator (semicolon on Windows, colon on Unices)
#extra_clusters=
How can I change (for a workaround) to the 32Bit starter "s3.exe"? What is
the problem with the 64Bit starter?
best regards,
josh.
arittner
2012-09-12 12:43:30 UTC
Permalink
Hi!
Hi,
Which version of nbm-maven-plugin are you using? This is a known issue if you run a RELEASE71 project with version 3.8 of the
Wow, quick response :-)

Yes. 3.8


Code:


<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<version>3.8</version>
<extensions>true</extensions>
<configuration>
<brandingToken>${brandingToken}</brandingToken>
<useOSGiDependencies>false</useOSGiDependencies>
</configuration>
</plugin>

<plugin>
<!-- netbeans modules in 6.9+ are 1.6 compatible -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
</plugin>

</plugins>
</pluginManagement>
</build>




Ok. I'l try an older version... Hope that helps.

Do you have an issue number?

Thank you.

br, josh.
arittner
2012-09-12 12:51:39 UTC
Permalink
Ok!

With 3.7. it works. The starter is now:

cmd.exe /X /C "C:\entw\Work\svn\4.2\apps\s3standard\target\s3\bin\s3.exe --console suppress --userdir C:\entw\Work\svn\4.2\apps\s3standard\target\userdir -J-Dnetbeans.logger.console=true -J-ea --branding s3 --jdkhome C:\entw\JDK\1.7.0_04"

Thanks. That work :)

br, josh.
Hermien Pellissier
2012-09-12 12:56:39 UTC
Permalink
Hi Josh,

Glad I could help. It took me about half a day to figure this one out
initially. :)

Configuring the application project to use a 32-bit JVM also works for
me. Application project properties > Build > Compile. Add a 32-bit Java
Platform (Manage Java Platforms... button) if you don't have one on the
drop down. And then select it. You might have to rebuild the parent.

This bug lives in the funny space somewhere between NetBeans and
the nbm-maven-plugin, and as such I mentioned it to the maintainer of the
plugin instead of logging it on NetBeans bugzilla. However, I just decided
maybe I should log a bug for traceability. So here is the brand new issue:
http://netbeans.org/bugzilla/show_bug.cgi?id=218211

Best wishes,
Hermien Pellissier
Post by arittner
Ok!
cmd.exe /X /C "C:\entw\Work\svn\4.2\apps\s3standard\target\s3\bin\s3.exe
--console suppress --userdir
C:\entw\Work\svn\4.2\apps\s3standard\target\userdir
-J-Dnetbeans.logger.console=true -J-ea --branding s3 --jdkhome
C:\entw\JDK\1.7.0_04"
Thanks. That work :)
br, josh.
Continue reading on narkive:
Loading...