This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 89623 - Cannot build a freshly checked out project
Summary: Cannot build a freshly checked out project
Status: VERIFIED DUPLICATE of bug 89629
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All Windows XP
: P2 blocker (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-19 20:44 UTC by Kirill Sorokin
Modified: 2006-11-21 08:59 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill Sorokin 2006-11-19 20:44:22 UTC
I have a simple java application project stored in CVS repository. All
interaction with it was done through NetBeans (and kudos to that team - it works
nicely). Obviously, the nbproject/private directory is ignored and is NOT put to
the repository.

The problem begins when I select a non-default java platform for the project. If
I check out the project (I mean a clean check out, i.e. on another machine or
into a new directory) and try to run any build target, it fails with "Platform
si not correctly setup" error. This is obviously due to the missing
nbproject/private/private properties, which would point to the
${userdir}/build.properties, which in turn would list the defined platforms.

The point of this report is that the build procedure should not fail, but should
issue a warning (smth like "The target platform name could not be resolved,
using current java home.") The current behavior makes it difficult to set up
automated daily builds for netbeans-based projects. I had to work around this by
manually supplying platforms.<platform-name>.home property which pointed to the
current ${java.home}.

--
I'm working with

NetBeans IDE Dev (Build 200610231500)
1.6.0-rc; Java HotSpot(TM) Client VM 1.6.0-rc-b104
Windows XP version 5.1 running on x86
ru_RU (nb); Cp1251
Comment 1 Jiri Prox 2006-11-20 09:48:19 UTC
The "private" directory should by created automaticaly when there is no such
folder. It is intended to not put it to repository while it contains full path
which can be different on each machine. You can override this behaviour by
modifying .cvsignore file in nbbuild directory.
Comment 2 Kirill Sorokin 2006-11-20 11:52:12 UTC
Sure it is created. But only when I open the checked out project in the IDE. The
use case is to build the project on a machine where there is no IDE. In this
case, putting private.properties under source control would not help.

It turns out to be impossible, given a specific project setup. If I use the
default java platform - the build script does not seem to care which java is
used when building from command line (this is bad by itself, btw - a warning
should be issued if I build with a different java version); but once I tell the
IDE to use a specific java platform - I cannot build anymore.
Comment 3 Milan Kubec 2006-11-20 15:16:58 UTC
I think it's duplicate of issue #89629. The problem will be addressed in next
version of NetBeans.


*** This issue has been marked as a duplicate of 89629 ***
Comment 4 Jesse Glick 2006-11-20 17:45:19 UTC
While GUI improvements are planned for a future release, you do not need them to
work with NB today. You just need to define the appropriate Ant properties in
your build process to point to your Java platform. That is not a workaround,
that is the expected process.
Comment 5 Kirill Sorokin 2006-11-21 08:59:05 UTC
Is it documented somewhere? I mean, the need to set
"platforms.<platform-name>.home" is not the most intuitive thing that I've ever
met. Or maybe I'm just missing something..

Anyway, with all the bloat about NB ant-based build system I did expect my
projects to be buildable (at least, to some extent) on any machine with or
without NB, and without me having to setup something additionally. In theory I
agree to make this an RFE (see the first comment - "do not fail - issue a
warning"), but the usability impact should be considered. Reopening for now, sorry.