Definitely exposing my newbie status with Maven!
However I worked on a HUGE project with Ant and we did exactly that,
ie had one source tree for all work. The way we stopped any
particular class from one package using one from an "illegal" package
was using various Ant masks, so that if for example you checked in
class com.acme.model.MyModel.java that had an import to
com.acme.ui.MyUI.java, it literally wouldn't compile as the Ant
script would let your particular code see that package and cruise
control would report an error.
In other words we solved dependency issues using java package based
rules, enforcing them with ant scripts. Believe me compared to many
projects I've been on it was a godsend seeing all the code in one
directory. We even used clearcase config specs so that we could see
just the code we were interested in so that our machines wouldn't
fall over with the strain.
With regards to eclipse read the following url http://mindprod.com/
jgloss/eclipse.html. For those that can't be bothered it explains how
Eclipse is essentially a structured database which shouldn't surprise
anybody who has previously used VisualAge when it wasn't ... well,
dead. In fact with VisualAge we never ever used to export the source
code to the filing system, we would just generate the customer
release jars direct onto CD ready for customer updates every couple
of months.
Cheers
- AW
On 1 Sep 2005, at 22:57, dan tran wrote:
On 9/1/05, Ashley Williams <[EMAIL PROTECTED]> wrote:
Thanks, that should get me going for now, at least for the compile
lifecycle (still need to think about recources etc). I'm actually
trying to figure out a much broader way of working, i.e. imagine
starting a project with a dozen developers all working on many source
files. Am I mistaken in thinking that Maven tries to get you to
define multiple source trees, one for each artifact?? If so then that
seems counter intuitive to me: surely there should be just the one
source tree with many maven projects applying their own masks.
The filters are there to help out with the transition from legacy
build
system
to Maven. Occational we may want to do some filtering even within a
maven
project.
Once source tree for many maven projects sound dangerous,
basically you
have the potential of
a maven project depends on every other projects indirectly via the
central
source.
To see where I'm coming from imagine a database of source code rather
than a file system, so that the only structure you have is on package
names in that database and not some added notion of there being
entirely separate areas both beginning with "com.". I understand that
Eclipse uses some sort of source code database and would love to know
Maven is bending in that direction also.
Also maybe it's already in the works, but I think there should be a
practical document on how to set up a large project using Maven as
I'm sure that would speed up its adoption.
I doubt eclipse is doing that.
Just a few thoughts anyway.
- AW
On 1 Sep 2005, at 22:06, dan tran wrote:
btw, this feature is not in alpha 3 thou, but the latest trunk
-D
On 9/1/05, dan tran <[EMAIL PROTECTED]> wrote:
in Maven 1, you use sourceModifications
in Maven 2, you use compiler plugin filter set
-D
On 9/1/05, Ashley Williams <[EMAIL PROTECTED]> wrote:
I have my source code on a single tree but wish to build two
artifacts out of it with two different poms. Is there some concept
such as a file set so that each project will only see the relevant
files for compiling and jaring etc?
Thanks
- AW
------------------------------------------------------------------
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
