Hi John,
Looking forward to the properties code btw
I don't expect Maven to provide me with something out of the box,
because I do understand it's priorities. In fact I don't think any
features are required (hopefully), just some way of puzzling how to
use the properties that are already there. As long as the plugins are
100% consistent in the way they use those properties, eg
outputDirectory, sourceDirectory etc, then hopefully there shouldn't
be any problem. Like you said it's just coming up with a use case, if
we mean the same thing.
I've added a few comments below...
On 8 Sep 2005, at 15:07, John Casey wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It seems to me that there was a JIRA filed for sourceModifications in
m2, but I think it's been pushed for now...maybe until 2.1, I dunno
for
sure.
I understand the position you're in, and that you don't really have
the
power to dictate a mass reorganization of your contractee's project
code. I believe we have some other use cases for this functionality,
where it's simply not practical to modularize the source tree in the
near- to medium-term. However, these sorts of features are doomed
to lag
behind the core functionality a bit, as they really are stop-gap
solutions that are only suitable for the short term.
I won't lecture you on the ins and outs of modular source trees - I'm
sure you know already - but I will mention one specific point, for
clarity. Having a monolithic source tree has a rather dramatic
ownership
cost. It means that everyone working on it must be concerned with
regressions across the tree, and it hides what would otherwise be
reusable and generally useful functionality from groups outside the
team
members that maintain that codebase. Therefore, for the longer term,
it's better to chop this stuff up and make a series of finer grained
artifacts that encapsulate some coherent, sane set of functionality.
Not sure I agree with your original assumptions. The java package
namespace is one thing and the carving up into component jar files
etc is another. The package namespace is monolithic whichever way you
look at it, ie it's always going to be one package tree. Having one
or many filesystem trees won't affect the source code authors one
jot, but it will have an impact how the deployment team go about
their business. Eg they will dictate that a certain file structure
convenient for the jar command (multiple fs trees), or they will
apply some filtering rules (single fs tree). Yeah I know, the
deployer is just the coder in a different hat ;)
For me I don't care whether the code is in a database, single fs tree
or multiple fs trees or even accessed through jndi, but I do disagree
that splitting up your filing system along the lines of your
component distribution is automatically a wise thing to do for any
given project.
It's a thin line to walk between the utility and coherence of
artifacts
we build on the one hand, and pragmatism on the other. We've simply
chosen to promote the former as a priority, with functionality related
to the latter lagging slightly behind. I assure you, we are interested
in making our product as generally applicable as possible, but we're
only a few people, and that means we have to set some priorities.
I hope you can be patient, and keep making good suggestions.
I will aim for a 0.5 s/n ratio, but I can't promise anything!
Thanks,
john
Ashley Williams wrote:
| Thanks for your response. In fact I'm equally comfortable
working with
| single or multiple source trees and see the benefits for both.
|
| However.
|
| As a contractor I don't have the luxury of going into any given
project
| and demanding that a budget be allocated to start splitting up the
| existing usually massive source structure - so therefore I'm
trying to
| find a way of using Maven on such projects. It's the difference
between
| saying:
|
| "There's this great build tool that we should be using, but we
do have
| to smash up the existing source structure. Somebody on the maven
| mailing list said it's easy so I don't mind sticking my neck on the
| block."
|
| vs
|
| "There's this great build tool that we should be using and the good
| news is that we can keep the single source tree and continue
using the
| existing build tools in the meantime"
|
| BTW the only reason I mentioned mapping drives because that's
what we
| did on a previous project - no I use Mac OS X at home and we're very
| happy thanks ;)
|
| In defence of single source trees, it's maybe easier to peruse the
| code. I'm trying to understand the maven project itself and am faced
| with maybe 100 different folders each with their own src trees. Will
| the eclipse plugin make a project out of all of that for example so
| that I can peruse and refactor the code? (Not rhetorical, I really
| don't know) At the moment I have to do a mdfind <filename>
(spotlight
| search, MAC OS X ;) ) to locate a maven file and then quickly
build the
| eclipse:eclipse project just there.
|
| ******
|
| I do understand that Maven can't support every file structure
out there
| but I would have thought the single source tree is a very
important and
| standard one. I suppose also that most maven users here will be
sold on
| multiple source trees by the definition of maven user.
|
| Anyway I believe I'm having some success and I will definitely
post up
| my findings for anyone who might be interested. Probably take a
while
| though.
|
| -AW
|
| On 8 Sep 2005, at 14:07, Andy Glick wrote:
|
|> At 07:09 AM 9/8/2005, Ashley Williams wrote:
|>
|>
|>> I work with many projects that are based around a single source
tree
|>> - by that I mean no matter how many modules and jars are build,
there
|>> is just one directory called com with all the code underneath
it. I'm
|>> not saying this is better or worse than the structure expected by
|>> Maven 2 out the box (don't want to sign up for that war!!), but I
|>> still need to find some practical solutions
|>>
|>> 1. The big one: is Maven 2 ever going to provide deliberate
support
|>> projects that are based around a single source tree? Or is it
deemed
|>> that the single source tree customers are too few to bother with.
|>>
|>> 2. Has anyone else gone through the same difficulties as I seem
to be
|>> having - I'd love to hear of your strategies.
|>>
|>
|> Ashley,
|>
|> For what its worth, I've been porting a number of projects to
M1 and
|> M2 by breaking up single source trees into the multiple
subprojects
|> "expected" by Maven. So far I've found that to work very nicely
and
|> from my perspective it actually makes the code much easier to
think
|> about and manage.
|>
|> I can't speak for the Maven developers, but I would think that the
|> likelihood of Maven's being reworked to support multiple artifacts
|> from a single source tree is low, unless for some reason a group
|> decides to fork the code. I think that if I were you, and I
wanted to
|> get at least some of the advantages of Maven but retain a non-
|> compliant single tree layout, I would scale back my expectations of
|> using many of Maven's features and use the M2 provided Ant
|> integrations to take advantage of as many Maven capabilities as
were
|> "easy" to access. Fighting one's toolset sounds like a most
|> unpleasant task to me.
|>
|> You might want to take a look at Javagen Jam, as it provides what I
|> have found to be a really nice Maven to Ant integration, and it
uses
|> the Ant import task to create importable, reusable chunks of Ant
|> code, which are not as expressive as Jelly, but can be very
powerful.
|> In addition you could look at using the Ant tasks presetdef and
|> macrodef in concert with the import task to create higher level
|> wrappers around existing Ant tasks.
|>
|> You mentioned drive mapping, so I imagine that you are
developing on
|> Windows. I realize that it is pretty ridiculous of me to
suggest that
|> you move your development to a Unix box, but Unix supports soft
|> links, which ought to make the task of simulating multiple source
|> trees from a single source tree much easier.
|>
|> As a possibility for the future, Trygve Laugstol is working on
|> creating an embedded M2 implementation. M2 is much faster than M1,
|> and Maven supports a -f <alternate-pom>.xml flag, so it might be
|> possible to break your required processing into a set of poms and
|> invoke them serially.
|>
|> Again, I would want to caution you, very few people ever win
fighting
|> city hall. :-)
|>
|>
---------------------------------------------------------------------
|> 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]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDIEWyK3h2CZwO/4URAjjOAKCYeGvLgXvdV04t0uD4qHkdMcJNugCglIAY
QC49okp7j2TQn0wyXPKiVec=
=u4sA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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]