Jump to content
Excelsior Forums
DerekPollard

Relative paths in project files?

Recommended Posts

Hi,

I am using JET for Windows and have JET and JetPackII projects that work from the GUI tools and building using Ant.  However I have the problem that I can only build using the directory that I originally created the project files as the full path names are stored within.  The stops me setting up continuous integration or even doing a build of a separate branch in a different area.

So my question is this:  How do I get JET and JetPackII to store relative paths in their project files?

I have manually edited the project files in the past but this is error prone and often fails due to the character encoding in the files.

Any help would be appreciated.

Cheers,

Derek.

Share this post


Link to post
Share on other sites

Thank you for the suggestion, however that is still a manual process.  At the moment I have a one step Ant build target going from a clean project through to the creation of the installer executable (provided I'm in the fixed directory).  I am planning to automate this to have each new integration build (not developer) created in a unique directory.

It looks as though each time I change the JET or JetPack projects my solution will have to be the following:

1. Make the changes in the user interfaces.

2. Copy the project files.

3. Edit the project files to make the paths relative.

4. Check in both sets of files.

5. The Ant build uses the relative path versions.

Cheers,

Derek.

Share this post


Link to post
Share on other sites

Derek,

the absolute paths you noticed when introspecting in the project file have misled you. Actually, when possible, JetPackII uses paths relative to the location of the project (.jpn) file not absolute paths.

Moreover, JetPackII supports automated builds of the installer without invoking the GUI. The xpack command line utility that comes with Excelsior JET can do that.

----------------details

Suppose you have built the files in directory \MyBuild that contains

  - MyProject.jpn (JetPackII project)

  - files and directories to be included in the installation

\MyBuild

  \SomePackageDir

  packageFile1

  packageFile2

  MyProject.jpn

Now you create another build in directory \MyBuild1

\MyBuild1

  \SomePackageDir

  packageFile1

  packageFile2

All you need to do is

  1) copy MyProject.jpn to \MyBuild1

  2) invoke xpack as

      xpack MyBuild1\MyProject.jpn -target <path to the resulting installer>

Both steps can be easily automated.

Command line interface of xpack is described in the JET User's Guide, chapter "Deployment automation", section "Deployment utilities."

--ZZ TOP

P.S. Please let us know if it meets you needs.

Share this post


Link to post
Share on other sites

Hi,

I tried your suggestion but was not successful.  As recommended, I copied my build area to another drive.  It appears that JetPackII detected the path change as you said, but it failed to modify the path when looking for the resources.

I have included the first error detected from running the command from Ant  with -verbose (the line breaks are mess, but I think it shows the problem).

    [exec] Current OS is Windows XP

    [exec] Executing 'xpack' with arguments:

    [exec] '../build/ScreenRest.jpn'

    [exec] '-target'

    [exec] './ScreenRestInstall.exe'

    [exec]

    [exec] The ' characters around the executable and arguments are

    [exec] not part of the command.

    [exec] JetPackII batch mode

    [exec] JetPackII has detected that this project was moved from 'E:\Source\J

ava\ScreenRest\ScreenRest\build' to 'D:\Temp\buildtest\ScreenRest\build'.

    [exec] The following warnings detected:

    [exec] E:\Source\Java\ScreenRest\ScreenRest\deploy\ScreenRest\releasenotes\

contentHeadings.xml does not exist

Thanks for the help, I'm sure I'll get there in the end.

Cheers,

Derek.

Share this post


Link to post
Share on other sites

Your project file ScreenRest.jpn must be placed in a directory that is a root for all package files, e.g.

  D:\Temp\buildtest\ScreenRest

or

    D:\Temp\buildtest

not in

    D:\Temp\buildtest\ScreenRest\build

The file "contentHeadings.xml" was not found because it resides in an upper directory relative to the project file location.

Share this post


Link to post
Share on other sites

Fantastic! That did the trick, you're a star  :)

I moved the project file higher up within the real build area and fixed some branding paths in the GUI.  Then when I copied the area, xpack detected the change and correctly pulled the resources from the new location.

I can now keep my one-step build without editing the JetPackII project (which I never got to work anyway!).  I want to make sure I keep my high rating on 'The Joel Test' http://www.joelonsoftware.com/articles/fog0000000043.html

Thank you very much for your help.  JET is a great product that I recommend whenever the opportunity arises.  I look forward to entering my product in the Application Gallery.

Thanks,

Derek.

Share this post


Link to post
Share on other sites

Hi Derek,

glad to hear that the problem is now solved. Probably, we must document build automation process more thoroughly, e.g. prepare a separate Knowledge Base article. Thanks for focusing our attention on this issue.

Do you have in mind any other improvements we could implement to ease automated builds?

With best regards,

--ZZ TOP

B)

Share this post


Link to post
Share on other sites

Bonus:  I've just tried moving the Jet project file up to the top level and opened it in the GUI.  On saving, it removed the absolute paths for the classpath entries and .module entries.  Now I don't need to edit that file either.

I agree that the documentation could be enhanced or a knowledge base article added.  It is only a shame that the path location flexibility is in the software but not obvious how to take advantage of it.

There is one omission I spotted; the entry for the splash screen bitmap (-splash) is not handled in the same manner as the other files and it stays as an absolute path, even when loaded in another area, referencing the original location.  I hand edited that line and fortunately it stays that way on future GUI changes to other settings.  I can certainly live with that as I won't be changing the name very often, if at all by now.  That is the only item I have found would benefit from changing.  Otherwise I'm fully set for automated builds, thank for asking.

Cheers,

Derek.

Share this post


Link to post
Share on other sites

Derek,

thanks for your notes. We will unify all the code working with full path names and improve the docs as well. Maybe it makes sense to add a new chapter (something like "Build automation") to the User's Guide and create a new KB article on this subject.

-- ZZ TOP

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×