Fulcrum dependency nightmare

[Angelo Turetta <at...@commit.it>]

I hope sooner or later someone will have some genius idea for solving 
the problem of inter-dependency between fulcrum components.

In the meantime, if some committer would try and build fulcrum from 
scratch, at least after every component version change, that would be 
beneficial to most of the community. (build from scratch = build from a 
fresh tree just checked out, after rm -R .maven/repository/fulcrum)

In my bi-yearly attempt at doing so, I produced the attached patch 
(please commit).

Also, any chance someone could post to some public repository 
jta-hib2.1.jar (in the hibernate maven group). It's quite hard to get a 
copy.

Thanks for your hard work,
( and may you all enjoy a happy 2005 )
Angelo Turetta

Re: Fulcrum dependency nightmare

["Henning P. Schmiedehausen" <hp...@intermeta.de>]

Angelo Turetta <at...@commit.it> writes:

>In my bi-yearly attempt at doing so, I produced the attached patch 
>(please commit).

Thanks a lot; I'll let Eric do the checkin.

Lections that I learned with Maven the very hard way and try to follow
with my software development:

Referencing
===========

- _never_ reference a -dev version in project.xml dependencies
  (Yes, that _is_ the most important rule :-) )

- when developing: use SNAPSHOT

- when releasing:  reference a released version
  if not possible: reference a timestamped version

  (Reason: Avoid at all costs, that a dependency for a released
  version changes right under you (or worse: changes under the a** of
  an unsuspecting user that tries to redo the build process that
  worked for you and now does not work for him)

- if you must reference a non-released dependency in a project.xml
  file that goes into a public repository,  _always_ use a
  timestamped version. 

  (make sure that the timestamped version is available through the
  public repositories and let the repository maintainers know that you
  referenced this version in a public version, so they should not 
  pull it)

Development
===========

- _always_ use SNAPSHOT in project.xml when referencing a dependency
  under development / when parallel developing an application and a 
  dependency

- upload your dependencies under development by using maven
  jar:install-snapshot into your local repository. maven will check
  this first and you have the libs locally which is good if you
  develop e.g. on a laptop.

- if you do parallel development and must put stuff into a remote
  repository, use a locally installed repository server and change the
  <distributionSite> and <distributionDirectory> tags

  (Oh, how am I eternal grateful that this is part of the POM and not
   the properties, where they could've been overridden by an automated
   build process. From this stems the "uh, sorry, I checked in a POM
   with wrong distribution tags" checkins. </sarcasm>) [1] [2]


Checking in
===========

- _never_ check in a project.xml file that contains SNAPSHOT dependencies
   into a public repository

- _avoid_ checking in SNAPSHOT dependencies into a private repository
  (sometimes you can't avoid it, but it will come back to bite you)

Uploading
=========

- Upload only released versions to public repositories

- Uploading snapshots is a bad thing. However, it is not possible (AFAIK)
  to just upload a timestamped version. So maven jar:deploy-snapshot has
  a justification for existence (See referencing above).

- If you have uploaded a version to a public repository, change the version
  number in its project.xml file. Never re-upload a version to a public 
  repository (unless you really goofed up), because md5 sums and timestamps
  will change and cause confusion (see also: commons-lang disaster)

I try to keep to these guidelines with my internal and external
development and so far, they seem to hold and tone down the dependency
confusion.

While maven offers some powerful mechanisms and concepts for
dependency resolving and fetching, the overall concept is IMNSHO quite
botched (and seems to be suited to a certain type of "fire and forget"
development, that I found to be not very stable in the long run).

	Regards
		Henning


[1] You should use a local "remote" repository anyway. Ibiblio is slow
and putting stuff there really reduces development delays. [3]

[2] avoid having maven.repo.remote inside a ~/build.properties file.
Put it into your project specific project.properties file to control
from which repository the build of a component pulls its dependencies.

This allows your internal software development to pull dependencies
from your internal repo and rebuilding external projects to pull from
the "official" repos.

[3] Quick and dirty way to build a local "remote" repository

- clean out your maven.local.repo
- build your app with ibiblio as remote repo. Add all missing jars to
  your local repo by hand
- Install webserver
- move your local repo so that it gets served by the webserver
- add 
    maven.repo.remote=http://<your webserver>/<repo path>
  to the project.properties of your project
- make the served directory writeable by you
- make sure that you can "ssh" into the webserver without a password
  (using ssh-agent and public/private keys)
- add

  <distributionSite>... your webserver here...</distributionSite>
  <distributionDirectory>... directory path on webserver here...</distributionDirectory>

  to your project.xml

- add 

  maven.ssh.args=-o ForwardX11=false

  to your ~/build.properties when necessary (yeah, that really took me
  a while to figure out)

- maven jar:deploy[-snapshot] should now put your project onto your local
  webserver

-- 

"In einem Abw�gungsprozess, wollen wir weiter regieren, hat sich die
SPD und die Bundesregierung und auch der Bundesfinanzminister f�rs
Weiterregieren entschieden und gegen die Ehrlichkeit" -- Oswald
Metzger, B�ndnis '90/Die Gr�nen, 12.11.2002

-- 
Henning Schmiedehausen     "We're Germans and we use Unix. 
hps@intermeta.de            That's a combination of two demographic groups
henning@forge.franken.de    known to have no sense of humour whatsoever."
                               -- Hanno Mueller in de.comp.os.unix.programming 



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org