You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Bert van Brakel <be...@aeldirect.com> on 2003/04/24 05:39:51 UTC
RE: Why no multiple locations of sources? - proposal
Let me propose another solution. For the impatient skip to the middle of
the email for the xml stuff.
If we first list the reasons for both single and multiple source
directories:
Single Source:
1.1. code maintenance is easier (we don't forget to change stuff in
other locations)
1.2. minimise the chance of file conflicts. Don't want to have different
locations refering to the same package with each containing a file with
the same name
1.3. multiple locations make it a nightmare if everyone uses different
locations, as each plugin will have to be made aware of it, and which
one does it use?
1.4 we really don't want to put multiple source locations in the main
project descriptor and clutter it up, and we don't want to have to
obscure properties to point to source locations
1.5 don't want maven core to have todo anything special and cause it to
become to big. we want to hand everything off to plugins.
Multiple sources:
2.1. our unique situation warrants that separating the source to
multiple directories within tha same project is a good thing because.
2.1.a) to put auto generated code in a different directory than the hand
written stuff, which took us hours to write and we don't want to
accidently lose it.
2.1.b) our product is divided up into a number of 'modules', but
splitting it over multiple projects makes code maintainance even harder
than multiple source directories. Unfortunately its a hack to make it
all work with maven. Life sucks.
2.1.c) seperate 'demo code' or 'code examples' from the main production
code. ditto above.
2.1.d) be really cool if a derived source could include a master source
location from another project.
So both camps have valid reasons. The question is how do we ensure
everyone has their wish forfilled?. A possible solution could be to have
your cake and eat it to.
I propose 'derived single sources'. We define where the single source
resides, then build it from the true source locations. All this requires
is a plugin which copies files from the true locations to the derived
directory, throwing an error if there's a conflict (ERROR!: DUPLICATE
FILES FOR DERIVED SOURCE :x). No special changes to maven core.
Once maven can be run in the background as a long lived process it could
continuosly copy and compile the derived sources to ensure there are no
conflicts. All it has to do is keep the plugin running. I don't imagine
it'll be hard (tell me if I'm wrong!) since the new maven is likely to
use plexus.
If we put all this info in another file called sources.xml, it's kept
out of the project.xml file where it doesn't belong, but is included in
the pom by maven, so is available to plugins. The current project.xml
won't need to change much as all the resulting source directories are
the same as is now. The build section will look like this:
.
Say like this:
<build>
<unitTest>
<includes>
<include>**/*Test.java</include>
</includes>
</unitTest>
</build>
and all the source stuff will be in in another file called sources.xml,
which maven automatically looks up (like maven.xml). Having a seperate
file keeps the project.xml clean and dealing only with meta info, and
the sources.xml only with sources. I guess moving the build stuff into
this file would also be a good idea.
<sources>
<derived-sources>
<source>
<id>java</id>
<dir>${maven.java.src}</dir>
<master>src.tools</master>
<master>src.demos</master>
<master>src.code-gen</master>
</source>
<source>
<id>unittest</id>
<dir>${maven.test.src}</dir>
<master>src.custom-tests</master>
<master>src.code-gen-tests</master>
</source>
</derived-sources>
<master-sources>
<source>
<id>src.tools</id>
<dir>${basedir}/src/tools</dir>
<description>Tools to convert poms</description>
<source>
<source>
<id>src.demos</id>
<dir>${basedir}/src/demos</dir>
<description>Demo stuff for new developers</description>
<source>
<source>
<id>src.custom-tests</id>
<dir>${basedir}/src/custom-tests</dir>
<source>
<source>
<id>src.code-gen</id>
<dir>${basedir}/src/code-gen</dir>
<description>Auto code generated stuff</description>
<source>
<source>
<id>src.code-gen-tests</id>
<dir>${basedir}/src/code-gen-tests</dir>
<source>
</master-sources>
</sources>
If defined master sources don't exist then they are ignored.
Maybe maven could enforce that only a set of predefined derived id's
exist(java,unittest,aspectj?) but shouldn't have a limit on master
locations. Better still if a set of common ids is defined, with clear
documentation on their meaning, then there seems no reason why no other
derived sources could exist. Maybe non-standard derived ids could just
generate a clear warning that this practise is not recommended.like
(WARNING! MAVEN DESIGN GUIDELINES ARE BEING IGNORED. NONE-STANDARD
DERIVED SOURCE TREES!). May even be a requirement that all jakarta
projects follow this guideline which is enforceable (by ignoring these).
In my view this would meet all the requirements more or less.
Custom plugins which deal with your master directories wouldn't need the
stuff in the sources.xml file as they work independtly, just like now,
but this setup does allow other plugins to capture this output through
derived sources without knowing squat about the master sources. Standard
maven plugins use only derived sources, custom plugins write use
whatever.
Using the description tags these sources can be automatically
documented,telling new developers what each source directory does.
The master source locations may even be wildcard expressions like
"${basedir}/src/master/*" indicating all directories under master are to
be top level master locations. I could live with dropping this idea
though, however it allows writing plugins which drop their output in an
arbitrary directory and still have it picked up by other plugins,
Only your ide setup (like eclipse:generate-project) plugin must be
modified to be aware of the master sources but that should be easy. Not
sure how your ide can be notified of non java conflicts without making a
maven plugin for your ide, but the ide should do most of this itself
with the java code (in eclipse that's true, I imagine idea and others
are similiar)
That's my thoughts on the matter. Feel free to comment.
-Bert
On Thu, 2003-04-10 at 21:14, michal.maczka wrote:
> > -----Original Message-----
> > From: Jason van Zyl [mailto:jason@zenplex.com]
> > Sent: Wednesday, April 02, 2003 5:10 PM
> > To: Maven Users List
> > Subject: Re: Why no multiple locations of sources? ( was Re:
> > inter-projectdependencies for the Eclipse plugin )
> >
> >
> > On Wed, 2003-04-02 at 09:05, Rafal Krzewski wrote:
> > > Jason van Zyl wrote:
> > >
> > > > That is distinctly different than multiple source directories for your
> > > > application. And here we are trying satisfy these
> > requirements and scale
> > > > by letting the plugins deal with these different requirements
> > instead of
> > > > trying to jam everything into the POM.
> > >
> > > I believe that the POM is the proper place for defining what goes in
> > > your project. Plugins should retrieve information from there and proceed
> > > with their work.
> >
> > I've pondered this many a time. I really do not like the idea of having
> > to augment your POM when you choose to use a plugin. I very much like
> > the way the antlr plugin works in that it just kicks in when certain
> > resources are present.
> >
> > > Right now many plugins rely on project.properties file
> > > rather than POM, wich I think is not right.
> > > Of course we should always use our best judgement to avoid cluttering
> > > the POM, but I thing that the source directories (java, aspect, unit
> > > test, and others that arise) are crucial for defining the project, and
> > > therefore they should be in the POM.
> > >
> > > I really like Michal's proposal with sources/source/type elements.
> > > It puts the emphasis on the plugins undestating a specific type of
> > > sources, and allows us remove funcitonality from Maven core -
> > > it only manages information on abstract source sets.
> >
> > Sorry but I'm not sure I follow. Adding this abstraction adds to maven's
> > core. Offloading all processing and definition to the plugin is the way
> > I want to move.
> >
> > > I think this kind of change that it's really worth pursuing.
> >
> > I'm not really in favour of this and much prefer the way the antlr
> > plugin works. I would like to see most of the <build/> element removed
> > and replaced with a place where you can define plugin settings if they
> > are required. We started this a long time ago and there was a proposal
> > that just never got implemented.
> >
> > > R.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Why no multiple locations of sources? - proposal
Posted by Bert van Brakel <be...@aeldirect.com>.
Guess I'll wait and see if the artifact stuff gets included and see how
that pans out. I'll stick to my wish for multiple source locations as I
see a need for it. If down the track someone successfully convinces me
of the error of my ways I *may* change my mind if I haven't turned into
a stubborn fool by then :)
-Bert
On Sat, 2003-04-26 at 00:10, Rafal Krzewski wrote:
> Bert van Brakel wrote:
> >>>>2.1.b) our product is divided up into a number of 'modules', but
> >>>>splitting it over multiple projects makes code maintainance even harder
> >>>>than multiple source directories. Unfortunately its a hack to make it
> >>>>all work with maven. Life sucks.
> >>
> >>Maybe, maybe not. Some projects may be even messed up so much that it's
> >>easier to start everthing over with well defined structure than try to
> >>glue all the stuff together.
> >
> > I agree, but in some cases it's designed like that for a reason. Can you
> > anticipate all project scenarios? Better have a flexible tool which can
> > handle the most number of scenarios (traded ofcourse against complexity)
> > and enforce *configureable* guidelines (ie project leads decide), than
> > to have these constraints programmatically hardcoded.
>
> Well, Maven project's ambition is providing guidelines for software
> projects development. The existing guidelines may not be well suited
> for a range of projects. In this situation, we should work on creating
> better guidelines, and then improve the tools to support these, not
> alter existing tools to work outside existing guidelines. These are
> two distinct paths to reaching one point -- that Maven does what you
> want, but I think that if you follow the first one, more people can
> benefit from that, and as a side effect you mach change your opinion
> on 'what you want' too :-)
>
> > Sure, many problems can be solved this way but should we be forced into
> > a particular solution becasue of our tools?. Tools are to do our
> > bidding, not the other way round. Sometimes things don't fit into the
> > little boxes we would like . The only constant is change, and to force
> > yourself into a solution which seems right now doesn't mean it'll be
> > right tommorow when something comes along which is slightly out of the
> > ordinary. If we can't use our tools to cope with them, then in my
> > opinion that's a pretty poor tool
>
> True, but you must decide for a solution, right? And you don't know if it
> will work for you in the future no matter how good it looks today?
> Both rigid and flexible guidelines have their advantages, and finding
> a balance is the most challenging part of the work.
> In a some sense, rigid guidelines force you to solve design problems
> before they can bite you, flexible gidelines allow you move on after
> you get bitten.
>
> > ... however it does allow maven to download a dependencies source code
> > into another folder, setup your ide environment and you're away
> > laughing. I guess though that's getting outside the scope of mavens
> > goals. But hey, what tool is used only for the purpose it was supposed
> > to? A good tool is flexible to work outside the box.
>
> When POMs are deployed into the repository, this will be trivial to do
> maven -Dpull.project=org.apache.commons/jelly-core
> -Dpull.dir=./jelly-core pull
> And the yet-to-be written pull plugin will download the POM, and use
> the sourceRepository property to checkout the project into the given
> directory.
>
> > Not sure if I entirely agree. It's similiar to your proposed artifact
> > idea. The master source are like the input to the artifact handlers
> > (resource repo's), the derived sources are the generated artifact, the
> > compilation plugin which generates the derived sources is like your
> > artifact handler. One difference is that I was thinking of using one
> > compilation plugin to generate all the derived sources ('artifacts'),
> > you are proposing a seperate one for each. I see your approach is even
> > more flexible but I think also *more* complicated, but also more inline
> > with the rest of the maven design patterns.
>
> It is more complex, and it requires changes in the infrastructure, but
> it's modular and easily extensible. I don't like the idea of a bulky
> monolythic compilation plugin that routes stuff around. It's also
> aligned better with existing patters.
>
> > ditto on that! instead of specifying goals which are the 'how', we
> > should specify the 'what'. So we say "to do this I need 'this'" and
> > maven works out how to get the 'this'.
> >
> > Guess it's like going to the shop. You say 'I need a such and such'.
> > They then run all their 'goals'
> > (charge,order,package,ship,unpack,deliver) and give you your 'need'.
> > You don't say, I need you to run your charge,order,package...
> > processes. You don't know about them, and they change from shop to
> > shop.
>
> It sounds exactly like the way unix make works! You generally ask it
> to make a target, which may be either a file (->artifact) or a 'dummy'
> target. Makefiles are recipes for generating specific targets, or
> meta recipes for generating one kind of file from another.
> You can sort of align it to what Maven does, but it's not very clear.
> I think that we could leverage better on 20+ years of make experience...
>
> R.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Bert van Brakel
IT/Programming/Webdesign
AEL IT Ltd
Unit 1, 5 Tanner St
Woolston Industrial Estate
PO Box 4658, Christchurch
Phone: 03 389 9411 (ext 703)
Fax: 03 389 1411
Mobile: 021 297 1796
www.aeldirect.com
Accounting | Finance | Marketing | Property | Webdesign
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why no multiple locations of sources? - proposal
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Bert van Brakel wrote:
>>>>2.1.b) our product is divided up into a number of 'modules', but
>>>>splitting it over multiple projects makes code maintainance even harder
>>>>than multiple source directories. Unfortunately its a hack to make it
>>>>all work with maven. Life sucks.
>>
>>Maybe, maybe not. Some projects may be even messed up so much that it's
>>easier to start everthing over with well defined structure than try to
>>glue all the stuff together.
>
> I agree, but in some cases it's designed like that for a reason. Can you
> anticipate all project scenarios? Better have a flexible tool which can
> handle the most number of scenarios (traded ofcourse against complexity)
> and enforce *configureable* guidelines (ie project leads decide), than
> to have these constraints programmatically hardcoded.
Well, Maven project's ambition is providing guidelines for software
projects development. The existing guidelines may not be well suited
for a range of projects. In this situation, we should work on creating
better guidelines, and then improve the tools to support these, not
alter existing tools to work outside existing guidelines. These are
two distinct paths to reaching one point -- that Maven does what you
want, but I think that if you follow the first one, more people can
benefit from that, and as a side effect you mach change your opinion
on 'what you want' too :-)
> Sure, many problems can be solved this way but should we be forced into
> a particular solution becasue of our tools?. Tools are to do our
> bidding, not the other way round. Sometimes things don't fit into the
> little boxes we would like . The only constant is change, and to force
> yourself into a solution which seems right now doesn't mean it'll be
> right tommorow when something comes along which is slightly out of the
> ordinary. If we can't use our tools to cope with them, then in my
> opinion that's a pretty poor tool
True, but you must decide for a solution, right? And you don't know if it
will work for you in the future no matter how good it looks today?
Both rigid and flexible guidelines have their advantages, and finding
a balance is the most challenging part of the work.
In a some sense, rigid guidelines force you to solve design problems
before they can bite you, flexible gidelines allow you move on after
you get bitten.
> ... however it does allow maven to download a dependencies source code
> into another folder, setup your ide environment and you're away
> laughing. I guess though that's getting outside the scope of mavens
> goals. But hey, what tool is used only for the purpose it was supposed
> to? A good tool is flexible to work outside the box.
When POMs are deployed into the repository, this will be trivial to do
maven -Dpull.project=org.apache.commons/jelly-core
-Dpull.dir=./jelly-core pull
And the yet-to-be written pull plugin will download the POM, and use
the sourceRepository property to checkout the project into the given
directory.
> Not sure if I entirely agree. It's similiar to your proposed artifact
> idea. The master source are like the input to the artifact handlers
> (resource repo's), the derived sources are the generated artifact, the
> compilation plugin which generates the derived sources is like your
> artifact handler. One difference is that I was thinking of using one
> compilation plugin to generate all the derived sources ('artifacts'),
> you are proposing a seperate one for each. I see your approach is even
> more flexible but I think also *more* complicated, but also more inline
> with the rest of the maven design patterns.
It is more complex, and it requires changes in the infrastructure, but
it's modular and easily extensible. I don't like the idea of a bulky
monolythic compilation plugin that routes stuff around. It's also
aligned better with existing patters.
> ditto on that! instead of specifying goals which are the 'how', we
> should specify the 'what'. So we say "to do this I need 'this'" and
> maven works out how to get the 'this'.
>
> Guess it's like going to the shop. You say 'I need a such and such'.
> They then run all their 'goals'
> (charge,order,package,ship,unpack,deliver) and give you your 'need'.
> You don't say, I need you to run your charge,order,package...
> processes. You don't know about them, and they change from shop to
> shop.
It sounds exactly like the way unix make works! You generally ask it
to make a target, which may be either a file (->artifact) or a 'dummy'
target. Makefiles are recipes for generating specific targets, or
meta recipes for generating one kind of file from another.
You can sort of align it to what Maven does, but it's not very clear.
I think that we could leverage better on 20+ years of make experience...
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why no multiple locations of sources? - proposal
Posted by Bert van Brakel <be...@aeldirect.com>.
On Thu, 2003-04-24 at 23:24, Rafal Krzewski wrote:
> michal.maczka wrote:
> >>From: Bert van Brakel [mailto:bert@aeldirect.com]
>
> >>2.1.a) to put auto generated code in a different directory than the hand
> >>written stuff, which took us hours to write and we don't want to
> >>accidently lose it.
> >
> > Well. You can always do things which will destroy your sources
> > and nothing can stop you from doing that.
>
> You could also try using CVS ;-)
already do, just don't want to have to update to cvs before running a
tool. The safer the better.
>
> >>2.1.b) our product is divided up into a number of 'modules', but
> >>splitting it over multiple projects makes code maintainance even harder
> >>than multiple source directories. Unfortunately its a hack to make it
> >>all work with maven. Life sucks.
>
> Maybe, maybe not. Some projects may be even messed up so much that it's
> easier to start everthing over with well defined structure than try to
> glue all the stuff together.
>
I agree, but in some cases it's designed like that for a reason. Can you
anticipate all project scenarios? Better have a flexible tool which can
handle the most number of scenarios (traded ofcourse against complexity)
and enforce *configureable* guidelines (ie project leads decide), than
to have these constraints programmatically hardcoded.
> >>2.1.c) seperate 'demo code' or 'code examples' from the main production
> >>code. ditto above.
>
> Reactored subprojects are the Maven way of solving this problem.
>
Sure, many problems can be solved this way but should we be forced into
a particular solution becasue of our tools?. Tools are to do our
bidding, not the other way round. Sometimes things don't fit into the
little boxes we would like . The only constant is change, and to force
yourself into a solution which seems right now doesn't mean it'll be
right tommorow when something comes along which is slightly out of the
ordinary. If we can't use our tools to cope with them, then in my
opinion that's a pretty poor tool
> >>2.1.d) be really cool if a derived source could include a master source
> >>location from another project.
>
> This kind of inter-project binding is useful in an IDE (BTW. I *love*
> Eclipse auto-building feature), but for ordinary builds (distributions/
> nightlies/continuous integration) I don't think it's a good idea.
>
thinking about it some more I agree with you. That was a bad idea. sorry
:)
... however it does allow maven to download a dependencies source code
into another folder, setup your ide environment and you're away
laughing. I guess though that's getting outside the scope of mavens
goals. But hey, what tool is used only for the purpose it was supposed
to? A good tool is flexible to work outside the box.
> > I am personally for changing a bit the situation of sources (I described my
> > idea some times ago)
> > But I am also for simplicity and I think that what you are proposing
> > is too complicated and I see easier ways to go.
>
> Ditto.
Not sure if I entirely agree. It's similiar to your proposed artifact
idea. The master source are like the input to the artifact handlers
(resource repo's), the derived sources are the generated artifact, the
compilation plugin which generates the derived sources is like your
artifact handler. One difference is that I was thinking of using one
compilation plugin to generate all the derived sources ('artifacts'),
you are proposing a seperate one for each. I see your approach is even
more flexible but I think also *more* complicated, but also more inline
with the rest of the maven design patterns.
>
> > Once we will be able to have artifacts like "java sources", "javadocs" etc,
> > (it's my wishful thinking) you will be able to explicitly express such
> > things using
> > dependencies. If we have a way of defining the artifact handlers for
> > different type
> > of artifacts + give a way to extend it ... this in my opinion will be much
> > better.
> > I really think that components/project should exchange information
> > through artifacts/dependicies/repositories and should not use other projects
> > sources directly.
>
> I really like your way of thinking. It's very much along my own thoughts
> on the issue. I'm looking forward to your work in this area for
> maven-new!
>
ditto on that! instead of specifying goals which are the 'how', we
should specify the 'what'. So we say "to do this I need 'this'" and
maven works out how to get the 'this'.
Guess it's like going to the shop. You say 'I need a such and such'.
They then run all their 'goals'
(charge,order,package,ship,unpack,deliver) and give you your 'need'. You
don't say, I need you to run your charge,order,package... processes. You
don't know about them, and they change from shop to shop.
cool
-Bert
> R.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why no multiple locations of sources? - proposal
Posted by Rafal Krzewski <Ra...@caltha.pl>.
michal.maczka wrote:
>>From: Bert van Brakel [mailto:bert@aeldirect.com]
>>2.1.a) to put auto generated code in a different directory than the hand
>>written stuff, which took us hours to write and we don't want to
>>accidently lose it.
>
> Well. You can always do things which will destroy your sources
> and nothing can stop you from doing that.
You could also try using CVS ;-)
>>2.1.b) our product is divided up into a number of 'modules', but
>>splitting it over multiple projects makes code maintainance even harder
>>than multiple source directories. Unfortunately its a hack to make it
>>all work with maven. Life sucks.
Maybe, maybe not. Some projects may be even messed up so much that it's
easier to start everthing over with well defined structure than try to
glue all the stuff together.
>>2.1.c) seperate 'demo code' or 'code examples' from the main production
>>code. ditto above.
Reactored subprojects are the Maven way of solving this problem.
>>2.1.d) be really cool if a derived source could include a master source
>>location from another project.
This kind of inter-project binding is useful in an IDE (BTW. I *love*
Eclipse auto-building feature), but for ordinary builds (distributions/
nightlies/continuous integration) I don't think it's a good idea.
> I am personally for changing a bit the situation of sources (I described my
> idea some times ago)
> But I am also for simplicity and I think that what you are proposing
> is too complicated and I see easier ways to go.
Ditto.
> Once we will be able to have artifacts like "java sources", "javadocs" etc,
> (it's my wishful thinking) you will be able to explicitly express such
> things using
> dependencies. If we have a way of defining the artifact handlers for
> different type
> of artifacts + give a way to extend it ... this in my opinion will be much
> better.
> I really think that components/project should exchange information
> through artifacts/dependicies/repositories and should not use other projects
> sources directly.
I really like your way of thinking. It's very much along my own thoughts
on the issue. I'm looking forward to your work in this area for
maven-new!
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Why no multiple locations of sources? - proposal
Posted by Bert van Brakel <be...@aeldirect.com>.
On Thu, 2003-04-24 at 21:02, Konstantin Priblouda wrote:
> > > 2.1.a) to put auto generated code in a different
> > directory than the hand
> > > written stuff, which took us hours to write and we
> > don't want to
> > > accidently lose it.
>
> If you look at xdoclet module, you will see that it
> places generated code outside of main source tree...
>
> so this is possible with current maven behaviour...
>
sure, not saying it's not. It's all about how easy it is. Do we have to
mangle maven to do what we want, or decide that since people are
violating 'maven guidelines' anyway, we allow them to atleast do it in
as tidy a manner as possible?.
-Bert
> regards,
>
> =====
> Konstantin Priblouda ( ko5tik ) Freelance Software developer
> < http://www.pribluda.de > < play java games -> http://www.yook.de >
> < render charts online -> http://www.pribluda.de/povray/ >
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
Bert van Brakel
IT/Programming/Webdesign
AEL IT Ltd
Unit 1, 5 Tanner St
Woolston Industrial Estate
PO Box 4658, Christchurch
Phone: 03 389 9411 (ext 703)
Fax: 03 389 1411
Mobile: 021 297 1796
www.aeldirect.com
Accounting | Finance | Marketing | Property | Webdesign
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Why no multiple locations of sources? - proposal
Posted by Konstantin Priblouda <kp...@yahoo.com>.
> > 2.1.a) to put auto generated code in a different
> directory than the hand
> > written stuff, which took us hours to write and we
> don't want to
> > accidently lose it.
If you look at xdoclet module, you will see that it
places generated code outside of main source tree...
so this is possible with current maven behaviour...
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Why no multiple locations of sources? - proposal
Posted by "michal.maczka" <mi...@cqs.ch>.
> -----Original Message-----
> From: Bert van Brakel [mailto:bert@aeldirect.com]
> Sent: Thursday, April 24, 2003 5:40 AM
> To: Maven Developers List; Maven Users List
> Subject: RE: Why no multiple locations of sources? - proposal
>
>
> Let me propose another solution. For the impatient skip to the middle of
> the email for the xml stuff.
>
> If we first list the reasons for both single and multiple source
> directories:
>
> Single Source:
>
> 1.1. code maintenance is easier (we don't forget to change stuff in
> other locations)
> 1.2. minimise the chance of file conflicts. Don't want to have different
> locations refering to the same package with each containing a file with
> the same name
> 1.3. multiple locations make it a nightmare if everyone uses different
> locations, as each plugin will have to be made aware of it, and which
> one does it use?
> 1.4 we really don't want to put multiple source locations in the main
> project descriptor and clutter it up, and we don't want to have to
> obscure properties to point to source locations
> 1.5 don't want maven core to have todo anything special and cause it to
> become to big. we want to hand everything off to plugins.
>
> Multiple sources:
>
> 2.1. our unique situation warrants that separating the source to
> multiple directories within tha same project is a good thing because.
>
> 2.1.a) to put auto generated code in a different directory than the hand
> written stuff, which took us hours to write and we don't want to
> accidently lose it.
Well. You can always do things which will destroy your sources
and nothing can stop you from doing that.
> 2.1.b) our product is divided up into a number of 'modules', but
> splitting it over multiple projects makes code maintainance even harder
> than multiple source directories. Unfortunately its a hack to make it
> all work with maven. Life sucks.
> 2.1.c) seperate 'demo code' or 'code examples' from the main production
> code. ditto above.
> 2.1.d) be really cool if a derived source could include a master source
> location from another project.
>
[..]
I am personally for changing a bit the situation of sources (I described my
idea some times ago)
But I am also for simplicity and I think that what you are proposing
is too complicated and I see easier ways to go.
Once we will be able to have artifacts like "java sources", "javadocs" etc,
(it's my wishful thinking) you will be able to explicitly express such
things using
dependencies. If we have a way of defining the artifact handlers for
different type
of artifacts + give a way to extend it ... this in my opinion will be much
better.
I really think that components/project should exchange information
through artifacts/dependicies/repositories and should not use other projects
sources directly.
regards
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org