Personal tools
You are here: Home
Log in


Forgot your password?
New user?
 

Modified items

All recently modified items, latest first.
Re: build system usability issues by David Welker, last updated: Feb 25, 2009 05:51 PM
Hi Dan, If you don't mind fixing it, feel free to do so. David Great, thanks. By the way, the build system is not setting java.lib.path so none of the actors using JNI will run. Are you working on this? If not, I'll fix it.   Previously David Welker wrote: Hi Dan, I have in fact checked in that file. Also, I have fixed the modules.txt problem by deleting it. Now, the value of modules.default will be used if modules.txt does not exist. David    
Re: build system usability issues by Aaron Schultz, last updated: Feb 25, 2009 04:59 PM
I would like to propose a new ant target for the build system. Currently Kepler excludes many packages and folders from Ptolemy.  However, when someone makes changes in Ptolemy and those changes introduce dependencies on classes that are excluded in Kepler then our excludes list needs to be updated (as is the case at the moment). Updating the Ptolemy excludes list is difficult to manually maintain especially since there are 4 copies of it in the build system, one for the ant build and three for the supported IDEs.  A simple algorithm could be implemented in an ant target that would greatly simplify this process. Here are the steps of the proposed algorithm: Read in the existing master ant build exclusion list Open and read in every java file in Ptolemy that is not excluded in the master exclusion list Check each import statement to see if there are any dependencies on excluded packages or classes, if there is an exclusion dependency add the current class to the exclusion list Recurse steps 2 and 3 until there are no more dependencies on excluded packages or classes print out the new exclusions to the screen so they can be manually examined and pasted into the master exclusions list   Another ant target would be useful for generating the IDE exclusion lists from the master ant build exclusion list .
Re: build system usability issues by Daniel Crawl, last updated: Feb 25, 2009 11:46 AM
Great, thanks. By the way, the build system is not setting java.lib.path so none of the actors using JNI will run. Are you working on this? If not, I'll fix it.   Previously David Welker wrote: Hi Dan, I have in fact checked in that file. Also, I have fixed the modules.txt problem by deleting it. Now, the value of modules.default will be used if modules.txt does not exist. David  
Re: build system usability issues by David Welker, last updated: Feb 24, 2009 04:34 PM
Hi Dan, I have in fact checked in that file. Also, I have fixed the modules.txt problem by deleting it. Now, the value of modules.default will be used if modules.txt does not exist. David
Re: build system usability issues by Daniel Crawl, last updated: Feb 24, 2009 12:11 PM
Hi David, Could you check in ReportDependencies.java? I'm getting the following error when running ant: build-area/build.xml:5: The following error occurred while executing this line: build-area/build-settings/taskdefs.xml:114: typedef class org.kepler.core.ant.ReportDependencies cannot be found Also, could we svn:ignore build-area/modules.txt? It changes frequently and usually is a different suite. thanks
Events by Kirsten Menger-Anderson, last updated: Feb 18, 2009 12:01 PM
Upcoming Events
Current Kepler Configuration System by David Welker, last updated: Feb 03, 2009 03:32 PM
This page documents all of the ways in which Kepler can be configured. The intent is to act as a reference for developers, but more importantly to gain an understanding of configuration as a whole so it can be simplified and rationalized.
Kepler Configuration by David Welker, last updated: Feb 02, 2009 03:03 PM
This folder contains pages that document the current configuration system used by Kepler and a proposal for a new configuration system that more fully integrates with modules.
Collaboration tools by Timothy McPhillips, last updated: Jan 31, 2009 05:23 PM
Re: moving to jdk 1.6 by Christopher Brooks, last updated: Jan 29, 2009 05:44 PM
Yep, I fully understand your point about supporting both 1.5 and 1.6, I've seen the compilation problems that occur.  Developers tend to use the latest and greatest, which is why the nightly build should under 1.5, if not both 1.5 and 1.6.  In the past, the Ptolemy project has released under multiple JDK versions because one size does not fit all, and there is no one choice that meets everyone's needs.  So, we should not require 1.6 until Eclipse easily runs under 1.6 on the Mac.  If we do this, then we lose people like Edward Lee who are on the Mac, use Eclipse, but are not likely to have time to jump through a large number of steps.  If we lose people like Edward, then we are likely to lose other potential developers.   Ptolemy II will not require 1.6 until Eclipse easily runs on the Mac under 1.6.  I'd like to make the switch to requiring 1.6, but cannot justify it at this time.   It could also be that the DBConnection code could be refactored so that it compiles under 1.5 and 1.6.  One issue is that I believe that the JDBC libraries are JDK dependent, so even if DBConnection was version neutral, we might still need to properly select the right JDB C jar file.  
Re: moving to jdk 1.6 by Matthew Jones, last updated: Jan 29, 2009 05:35 PM
The NMI nightly builds are running on 1.5, so presumably any 1.6-specific code would cause the nightly build to fail.  That said, its probably better to avoid that situation altogether.  If we do move to support 1.6, we could easily run the NMI build on both 1.6 and 1.5 by just adding in the 1.6 prereq as one of the build configurations.  This would mean the NMI build would be running on Mac, Ubuntu, Fedora, RH, and Windows, each with a build on each of 1.5 and 1.6.  It would take a while (although the builds happen in parallel). Matt
Re: moving to jdk 1.6 by David Welker, last updated: Jan 29, 2009 05:20 PM
Getting the build to change which version of the DBConnection is used depending on the version of Java that is being run by Ant wouldn't be that tricky. (Note that Eclipse users who want to change to 1.6 are still going to have to perform the above steps manually. I can only provide support in the build for the command-line. I suppose if it might be possible to build add a command that makes all the changes necessary on the Mac) Here is the issue. Should we provide support to 1.6 before we are ready to require 1.6? As soon as developers start checking in 1.6 only features into the code base, they are going break Kepler for those who insist on using 1.5. I suppose that isn't so bad for a non-core module meant to be used by people who are committed to going to 1.6... What is the advantage of developers not willing to force users of their modules to use 1.6 of allowing them to use 1.6 now if we can't use 1.6 features? The only advantage I know of is that the execution speed is a faster. Is this advantage worth making using 1.6 easier given the risk of inadvertently using a 1.6-only feature? In my view, I think it makes sense to go to 1.6 all at once and actually require it, because I think it would be simpler for developers and it keeps out the confusion from having two different versions of DBConnection.java (and who knows whatever classes in the future) from hanging around. Also, it is certainly an extra step for a developer to confirm that whatever library features they choose to use (and which work fine for them) are backwards compatible with 1.5, especially given the ability of modern IDEs to perform autocompletion and even provide method documentation right there on the fly. I haven't yet heard a compelling rationale for not upgrading. Is there anyone out there running a machine where upgrading to 1.6 (if they don't already have it) would be impossible or extremely difficult? I don't think the simple steps I outlined above are too burdensome for Mac users who choose to use Eclipse, especially since they only have to be performed once.
Re: moving to jdk 1.6 by Christopher Brooks, last updated: Jan 29, 2009 04:21 PM
Thanks for the detailed instructions.  It seems like we should continue to support Java 1.5 until Eclipse runs under Java 1.6 without jumping through lots of hoops.  The primary issue is that getting Eclipse to work is bad enough as it is, the subversive plugin setup is tricky etc.  Many Eclipse users are fairly new at this, so I'm loath to ask them to do too much.  Eclipse is pretty much the IDE of choice in this area, we should probably try to make it as simple as possible for these users. Any ideas on what would be involved with supporting both versions of Java in the build system?  I'd be happy with a fairly brute force method of just copying files around when "ant change-to" was run.  It seems like handling different versions of the OS could also be done by in similar fashion to how the build system should check to see if optional packages like Java3D are present. _C
Re: moving to jdk 1.6 by David Welker, last updated: Jan 29, 2009 04:05 PM
To use Java 1.6 to build the project with Eclipse and from the command-line but to still keep Eclipse running, there are a couple of fairly simple steps you need to take. (1) To change the version of java that works at the command-line, got to Applications->Utilities->Java->Java Preferences and change the Java version in both panes to 1.6 (64-bit). This is not enough though. If you type "ant -diagnostics" you will see that the version of Java used by ant is still 1.5. So, you need to change that as well. Right now, Eclipse still works. (2) To change the version of Java that ant uses, you need to change the symbolic link. Use the following commands: cd System/Library/Frameworks/JavaVM.framework/Versions sudo rm CurrentJDK sudo ln -s 1.6 CurrentJDK This will change the version of Java that ant uses. Confirm this by typing "ant -diagnostics." After this change, Eclipse will stop working too... (3) Go to the folder which contains the eclipse icon and right click and select "Show Package Contents." Inside the folder, open the Info.plist file. Towards the bottom of this very short file there will be lines that you can uncomment that will make Eclipse use a particular version of Java instead of the default version. In particular, uncomment the following line: <string>-vm</string><string>/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java</string> This will make it so that when Eclipse runs, it uses Java 1.5 instead of whatever the default version is. In this way, you can set Java 1.6 to work from the command-line and from ant, but ensure that Eclipse still uses Java 1.5, which it requires. Eclipse will now work again. (4) To ensure that Eclipse compiles with Java 1.6, go to Preferences. Select Java->Compiler and change the "Compiler compliance level" to 1.6. This will enable you to use 1.6 features in your code. (5) Make sure that the version of org.ecoinformatics.util.DBConnection that you are using is the 1.6 version rather than the 1.5 version. This class is in the the core module. === That is pretty much it. For the most part, it is perfectly possible to use Java 1.6 in Mac OS X 10.5. I think some earlier versions of OS X might have some problems because they do not support Java 1.6.
Building (and running) OSGi Kepler with Eclipse by Aaron Schultz, last updated: Jan 29, 2009 01:25 PM
This page explains how to build the monolithic Kepler OSGi bundle from the svn repository using Eclipse.
Linux by Aaron Schultz, last updated: Jan 29, 2009 01:25 PM
These are instructions for running the OSGi implementation of Kepler on Linux (Tested with Ubuntu 8.04). This implementation is still very much a work in progress and should only be used by Core developers for now.
Mac OS X by Aaron Schultz, last updated: Jan 29, 2009 01:24 PM
These are instructions for running the OSGi implementation of Kepler on Mac OSX. This implementation is still very much a work in progress and should only be used by Core developers for now.
Windows by Aaron Schultz, last updated: Jan 29, 2009 01:24 PM
These are instructions for running the OSGi implementation of Kepler on Windows. This implementation is still very much a work in progress and should only be used by Core developers for now.
Re: moving to jdk 1.6 by Derik Barseghian, last updated: Jan 28, 2009 03:23 PM
Christopher, yes, I've been juggling similar chicken-egg issues on my mac. I agree with your 'bottom line'.  Build team, do you have an idea on how difficult it would be to do this? I've just tried switching my system default to 1.6 (1.6.0_07 -- same steps as in your link), and I get the same error that prevents Eclipse launch as you, and sadly I'm using a very recent Eclipse:  Version: 3.4.1  Build id: M20080911-1700
Re: moving to jdk 1.6 by Christopher Brooks, last updated: Jan 28, 2009 02:32 PM
Hi Derik, Right, I can run Kepler under Java 1.6.  However, if Java 1.6 is in my path, then Eclipse does not work very well.  So, more precisely, to run Eclipse with Ptolemy or Kepler on the Mac, you need Java 1.5.  The Kepler or Ptolemy process itself may be run under Java 1.6, but there is this chicken and egg problem: If I have Java 1.6 in my path first, and DBConnection is changed:  cd core/src/org/ecoinformatics/util/  mv DBConnection.java DBConnection-JDK-1.6-Java  cp DBConnection-JDK1.6-Java DBConnection.java Then ant will properly build Kepler and I can run Kepler from the command line.  However, Eclipse will fail to start up. If I have Java 1.5 in my path, then I can use ant to build Kepler, but if I start up Eclipse under Java 1.5 and then run Kepler under Java 1.6, I need to make the above change to get it to compile. Maybe Eclipse has changed and a newer version works better with Java 1.6 under the Mac.  I'm running 2.0.1v200809-16-1301. This all seems a little complex, especially for a new Eclipse user.  The bottom line is that I think we need to support both Java 1.5 and 1.6 in the near term.  Ideally, the build system would recognize which version of Java is being used and act accordingly.
 
« Previous 20 items Next 20 items » 1 … 24 25 26 27 28 29 30 … 46