 |
BorlandTalk.com Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Mark Lassiter Guest
|
Posted: Fri Aug 08, 2003 5:56 am Post subject: Packages and Team Development |
|
|
Hello,
No sure what the right place is for this post, but here goes.
We have several developers using Delphi and constantly run into the same
problem with our various projects: installed packages. Not all developers
have the same packages installed, or the same version, or in the same path.
As a result, anytime someone needs to work on a project for the first time,
it's a real chore trying to get them configured with all the proper packages
for working on the project.
We have considered several options, including creating a Delphi Package
Collection (DPC) file for all our standard components, but that still
doesn't address things like versioning the packages by project, etc.
What we would like to end up with is what we have with our Java programming.
In java, we place all the library files needed by the project (jar files) in
a lib directory under the project. The ANT build script for the project
just relies on relative paths and the entire project can be built simply by
checking the project out and running the script. No special configuration
or worries about where you checked it out to as all paths are relative and
all libraries are included. This also means different projects can use
different versions of the same library and yields a reproducable process for
building the project.
In Delphi, it would be great if there was something like that. For example,
when you open the project file, it would automatically install all the
packages configured in the project, typically found in the project
directory. This would yield a much larger footprint as the same bpl files
would be everywhere, but it would make team development a snap and would
allow for a reproducable process.
I realize there are the package exclusion options per project, but as other
posters have mentioned, this buys you very little as the target developer
still needs to make sure the package is installed in the first place.
So, if anyone has any ideas or examples on how they use Delphi in a team
environment and how they address these issues, I would greatly appreciate
you sharing them.
If any borland folks are reading, please consider this hurdle in future
releases.
Thanks,
Mark
|
|
| Back to top |
|
 |
Michael Brown Guest
|
Posted: Fri Aug 08, 2003 7:07 am Post subject: Re: Packages and Team Development |
|
|
"Mark Lassiter" <mlassiter (AT) lassiterconsulting (DOT) net> wrote
| Quote: | Hello,
No sure what the right place is for this post, but here goes.
We have several developers using Delphi and constantly run into the same
problem with our various projects: installed packages. Not all developers
have the same packages installed, or the same version, or in the same
path.
As a result, anytime someone needs to work on a project for the first
time,
it's a real chore trying to get them configured with all the proper
packages
for working on the project.
We have considered several options, including creating a Delphi Package
Collection (DPC) file for all our standard components, but that still
doesn't address things like versioning the packages by project, etc.
What we would like to end up with is what we have with our Java
programming.
In java, we place all the library files needed by the project (jar files)
in
a lib directory under the project. The ANT build script for the project
just relies on relative paths and the entire project can be built simply
by
checking the project out and running the script. No special configuration
or worries about where you checked it out to as all paths are relative and
all libraries are included. This also means different projects can use
different versions of the same library and yields a reproducable process
for
building the project.
In Delphi, it would be great if there was something like that. For
example,
when you open the project file, it would automatically install all the
packages configured in the project, typically found in the project
directory. This would yield a much larger footprint as the same bpl files
would be everywhere, but it would make team development a snap and would
allow for a reproducable process.
I realize there are the package exclusion options per project, but as
other
posters have mentioned, this buys you very little as the target developer
still needs to make sure the package is installed in the first place.
So, if anyone has any ideas or examples on how they use Delphi in a team
environment and how they address these issues, I would greatly appreciate
you sharing them.
If any borland folks are reading, please consider this hurdle in future
releases.
|
I think TeamSource is supposed to handle this, but I don't have Enterprise
(or TeamSource) so I can't check. I've used CVS in several different
situations, and find that it is very good as you can set dependencies,
release points, etc. And it's free :)
--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open
|
|
| Back to top |
|
 |
Mark Lassiter Guest
|
Posted: Sun Aug 10, 2003 5:13 pm Post subject: Re: Packages and Team Development |
|
|
Thanks for the response. TeamSource and CVS address source code versioning,
but the issue with packages goes beyond that. In fact, we use CVS and
SourceSafe now (depending on client).
What we would like to be able to do is tell a developer: checkout project X
from source control. Once checked out, all they should have to do is open
the project, no further configuration required. All required packages are
automatically installed if need, etc. When the project is closed, they are
removed/uninstalled from the IDE. The packages, to provide appropriate
version for the build, are kept with the project.
This would provide the level of team development found in JBuilder or when
using CVS in conjunction with ANT and properly structured project folders.
I have found a tool called WANT that provides ANT like build capabilities,
but it doesn't address the IDE configuration problem.
| Quote: |
I think TeamSource is supposed to handle this, but I don't have Enterprise
(or TeamSource) so I can't check. I've used CVS in several different
situations, and find that it is very good as you can set dependencies,
release points, etc. And it's free :)
--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open
|
|
|
| Back to top |
|
 |
Mark Lassiter Guest
|
Posted: Sun Aug 10, 2003 5:27 pm Post subject: Re: Packages and Team Development |
|
|
Since my post, I have done the following:
Written an IDE wizard that registers an IDE Notifier. This notifier will
respond to project change events. For now, it simply looks for a pkgs
subdirectory under the newly loaded project. If found, it scans the
directory for bpl files and loads them using LoadPackage. It also looks for
the Register method and calls it.
When the project is closed or the user changes to another project, the
packages loaded are unloaded.
Problems I've run into are:
1. The register procedure name is mangled. I want to make sure I can make
assumptions about how it's mangled.
2. How do I "unregister" the components registered when the package was
loaded?
3. The resources are not loaded, so the bitmaps associated with the
components are not show on the pallete.
But I think it proves the concept. With this, I can place any packages
specific to a project in the projects pkgs directory. Others, that are
always used and commercial packages can be installed "globally".
Before continuing, I'm hoping someone from Borland might be able to provide
guidance to the above problems. Specifically, I'm hoping there is an easier
way to tell the IDE to install and uninstall a package. If nothing that
simple is available, then I'd like to make the exact same calls the IDE
makes.
Thanks in advance for any help,
Mark
|
|
| Back to top |
|
 |
Mark Lassiter Guest
|
Posted: Sun Aug 10, 2003 5:43 pm Post subject: Re: Packages and Team Development |
|
|
Edit to my last post: The bitmaps do show up OK, the specific package I was
using did not have a bitmap associated with it :)
But now the other concern is that the mangled name depends on the unit the
register procedure is found in and not all packages are created equal :p --
so I'll definitley need a cleaner way to do this.
Thanks,
Mark
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|