Re: Multiproject:site OutOfMemory

[Rafal Krzewski]

Carlos Sanchez wrote:
Hi,
I've experienced the same problem when compiling with aspectJ compiler
(maven-aspectj-plugin) and solved it with plugin properties: enabling fork
and setting maxmemory to 128MB.
AFAIK other plugins like maven-test-plugin have also fork options.
Dion, if you manage to add a fork option to the xdoc plugin, so that the 
xdoc -> html transfromation will hapen in separate vm, it will probably 
fix the problem for me, Matt and others.

Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiproject:site OutOfMemory

[Rafal Krzewski]

Dion Gillard wrote:
Generally looking for patterns about where it's failing. e.g. always
during xdoc or always during XXX.
In my case, I was getting java.io.IOException: failed to allocate memory 
when launching javadoc.

This problem was strictly related to the amout of xdocs transformed to 
html up to that point. Disabling plugins that generated many xdocs (like 
statcvs plugin) made it disappear.

Dion, please take a look at my analysis in 
http://jira.codehaus.org/browse/MAVEN-1294

xdoc transformation leaks huge amounts of memory. All TagScript objects 
ever instantiated stay permanently glued to app main thread. Same thing 
for JellyContext local XML parsers (!!!) - they never get GCed.

Jason argued that Jelly is broken beyound repair, and we should wait for 
the lightweight xdoc transformer from m2 to be backported to m1.

Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiproject:site OutOfMemory

[Rafal Krzewski]

Matt Read wrote:
 
http://jira.codehaus.org/browse/MAVEN-1294
 
Could anyone comment on the above defect or suggest resolutions or
work-arounds? I'm having the same problem as many seem to have reported
(currently with RC3) and it's driving me mad. I'm running multiproject:site
and I've enabled -verbose:gc with a max heap-size of 1024meg and just before
I get the OutOfMemory error GC reports only using 80meg - how can that be?  
You're out of luck Matt. This issue arises from problems in Jelly, and 
was deemed "not worth fixing" by the powers that be. Just wait a year or 
so for m2 catching up with functionality.

As for workarounds, you can start a multiproject build (to generate main 
docs), wait for it to crash, then build the sites of the remaining 
projects manually, lastly, copy over all of the generated site docs into 
the main multiproject docs. You can write a shell script/batch file to 
automate that.

Another possible workaround is hacking the xdoc plugin to spawn a 
separate vm for doing the xdoc -> html transformations. I think that 
somebody wrote he's doing it this way, but I haven't seen the code.

Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jars without version

[Rafal Krzewski]

Ian Neruda wrote:
Hi.
Can I install jar to repository without version part
in it. When I leave version empty I get something like
JarName-.jar
Artifacts in the respository should *always* have version numbers in 
them. This mandated by Maven internal contracts. If you need your jar 
with version number removed, you can copy + rename it from the 
repository to the place where you need it. It's very easy to do in your 
maven.xml

Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Mevenide releases

[Rafal Krzewski]

Maczka Michal wrote:
Yeap! You right. I am almost sure that I read somewhere taht m9 = rc1.
Almost right. M9 == RC0
Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Reactor infinite loop

[Rafal Krzewski]

Ian Neruda wrote:
-Maven
  -projects
-maven.xml
-Project1
-Project2
 

Maven.xml looks like this:



Am I doing something wrong?
Yup. The reactor includes itsef in the build, which casuses infiniter 
recursion. Try adding the following attribute.

excludes="project.xml"
hope this helps
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SNAPSHOT and multiproject

[Rafal Krzewski]

Gilles Dodinet wrote:
it is possible to modify it through a direct call to the currentVersion 
setter :

  ${pom.currentVersion}
  ${pom.setCurrentVersion("SNAPSHOT")}
  ${pom.currentVersion}
Eeek! It may be possible, which does not mean that it is right. Seems 
like a good start to turning your build system into a WMoPC (Writhing 
Mass of Primal Chaos, for the non-ADOM types :-))

Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven - Confluence integration

[Rafal Krzewski]

Jason van Zyl wrote:
It is clipping along at a rapid pace, if you want to try and build with
it we can arrange something. Before the alpha is released I'll probably
ask various folks to do some pre-alpha testing. There are about 14
plugins so far that are being used for testing, but the core will do the
trick as far as building jars. Just let me know and I'll throw you the
password for the bundles created by the CI process.
Too busy ATM :-(. But when you are in the pre alpha testing phase, I'm 
willing to participate. Put me on the list.

Rafal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Réf. : & in href in xdoc

[Rafal Krzewski]

Heritier Arnaud wrote:
yes I think that your problem is the one defined in MPXDOC-92.
Has there been any progres on this bug? It has large impact, because all 
the viewcvs links generated by the changes & statcvs plugins turn to 
garbage. Linkcheck gives me some 1mB error report :-)

R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javadoc on generated source directories - valid point!

[Rafal Krzewski]

Denis McLaughlin wrote:
  I don't think using a maven.compile.src.set property value (as it is
in your patch) provides the same benefits as the maven.compile.src.set
path refid.  Users are bound to miss something if we make them add all
the appropriate paths to the project.properties file: it may not be
obvious to the user which directory is holding the generated code, and
the directory may change from release to release of the plugin.  It
would be possible to work around this problem by expecting plugins to
append paths to the maven.compile.src.set property, but this would just
duplicate existing functionality (as mentioned, antlr and castor are
already appending paths to the path refid), and holding multiple paths
is really what path refids were intended for, I think, since they take
care of figuring out the path separator and so on.
>
Is there some value to using the maven.compile.src.set property rather
than the path refid?
I totally agree. Path sets seem superior in this regard to text 
properties. Maven even contains some jelly tags to help with path set 
manipulation if my memory servers me.

Is there any reason for using text properties? If not, how hard would it 
be to change Arnaud's recent contribution to user path sets instead?

Rafal.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven - Confluence integration

[Rafal Krzewski]

Jason van Zyl wrote:
So I started yanking out confluence docs and converting them to apt:
http://www.xmlmind.com/aptconvert.html
After realizing the internal format of confluence is crap I just started
using apt itself which I think is a better format anyway (I was
convinced by Pete Kazmier) but I still have my confluence to apt stuff.
Nice! Does it use the RPC interface (can't remember if it's XMLRPC or 
SOAP) to pull all the stuff, or do you need to do a manual export and 
then it processes the dowloaded xml files?

I've got lots of stuff if you want to look at it. 
Does it have a form of maven plugin? Or anything that could be easily 
adapted as such? If so, what about importint it into the plugins 
sandbox? I could look at it later this week.

We already have full apt -> xdoc, to go the other way probably wouldn't
be hard at all to create an initial import.
Should be even easier than the other way. Since xdocs are xml there are 
plenty of options ranging from xslt or vsl (not used in maven AFAICT) to 
jsl and java class traversing dom4j or plain dom documents.

> But ultimately I think
> I'm going to make something that uses the apt format and by pass
> confluence, it's format and radeox all together. Regexes are proving not
> to cut the mustard. I think the apt format would make an idea wiki and
> blog format but I'm all for using confluence for now. Pete Kazmier
> started the work and I finished the job of getting apt's license changed
> from LGPL to the MIT license.
> It would probably take
someone a week to whip off a simple webapp to edit apt documents online
which would be very cool.
I don't think I would swithch from Confluence to a webapp  that some one 
whipped off in a week any time soon :-D But sure, diversity is good. I 
don't know about Confluence internals, but maybe  in the future the 
Atlassian guys will give an option to choose the rendering engine at the 
time of deployment. This way people could use Radeox, or APT, or their 
favourite toy rendering library if they care enough to wrap it and toss 
it into the webapp.

Rafal
PS. I'm tracking the m2 progress, and I'm really happy with what I'm 
seeing! I wish I could take a part in that...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven - Confluence integration

[Rafal Krzewski]

Hello world,
I'm wondering how much of the Maven community uses Confluence as well. I 
do and I certainly like that.

Some time ago someone Nick Minutello wrote in his blog (can't find the 
link ATM, sorry) that he is working on a maven plugin that would 
tranform xdocs into Confuence compatible format and push them onto a 
server throgh the RPC interface.
The effect - all documentation is viewed and edited through the 
confluence. Now, what about maven reports which are generated as xdocs? 
Should they be be pushed up to confluence too? But my projects generates 
160 xdocs, totalling over 2.6MB of xml markup. Nah, I don't think so...

Bob McWhirter took an opposite approach. He wrote a perls script 
(allegedly called "confluenza") that pulls Confluence content down and 
generates a set of static html pages. You could see the result on 
http://timtam.codehaus.org/ Notice the "Edit" link at the right bottom 
corner of the page. J Aaron Farr described it on his blog:
http://www.jadetower.org/muses/archives/51.html
I pesonally like this approach better than the other on - serving static 
html is simply faster - but what about my maven reports?!

Therefore I think a combined approach would suit me best. A confluence 
plugin that would be able to:

1) push my existing xdocs (the hand written ones of course) up to 
confluence, so that I may edit them online.
This part could be assimilated from Nick's hypothetic (or not?) plugin

2) pull docs from Confluence and turn them into xdocs, so that they get 
processed by the xdoc plugin and turned into static html. The maven's 
navigation.xml should also be generated in that proces based on the page 
parent-child relationships.
Actually, navigation.xml processing would need to become more flexible - 
I still would like to define vertical toolbar links, and custom menus 
referncing maven generated reports, the confluence docs should go into a 
"Documentation" menu, or something.
This is similar to Bob's approach, but would have to be implemented in 
Jelly, or preferably as a POJO for easy m2 generation, and obviously the 
output grammar is different.

Too bad that I'm swamped with other work now, so I'm just tossing ideas 
around... Any takers? I'm willing to do the testing / reviews if someone 
is willing to work on implementing it.

Rafal

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Maven on a very large integration project - how far can Maven go?

[Rafal Krzewski]

Tomasz Pik wrote:

if war plugin finds 'war' dependency then un-war it and merge content
of dependency war into created war.
At least web.xml files should be merged together, probably more
descriptor files too - but this may be done as postGoals.
I don't think that merging web.xml or other files is a good idea. The 
logic for that has a good chance of becoming obscure and fragile.
I would just make the dependant project files override the dependencies 
files. Simpler & more predictable...

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion for using multiproject and cruisecontrol

[Rafal Krzewski]

nicolas De Loof wrote:

You can solve this by creating a virtual CVS module that has all of 
your 5 modules "mounted" as subdirectories.

Just out of couriosity I checked cvs manuals, and did a little test. 
This is what you should put in the CVSROOT/modules file, provided that 
you have modules m1and m2  your repository

p1m1 -d p1/m1
p1m2 -d p1/m2
p1 -a p1m1 p1m2
then, checking out module p1 will give you the desired result.

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion for using multiproject and cruisecontrol

[Rafal Krzewski]

Emmanuel Venisse wrote:

How to set CruiseControl to checkout the 5 CVS modules and run
"multiproject:install" and "multiproject:site" ?
Would it be easier if I had only one CVS module with subdirectories ?
   

Yes, it's the better option if it's really subprojects and not external
projects.
 

Maybe, but unfortunatly this is not an (easy) option with Eclipse...

Notice we are using Eclipse for devs, so CVS modules are set on the same
directory levels as eclipse projects are.
   

You can solve this by creating a virtual CVS module that has all of your 
5 modules "mounted" as subdirectories.

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Javadoc plugin don't copy doc-files directories ?

[Rafal Krzewski]

Sébastien BRUNOT wrote:

Hello,

It seems to me that the javadoc plugin does not copy the doc-files
directories. Is it a known bug or a misconfiguration from myself ?
 

I also had this problem lately, but did not have time to investigate. 
I'm under impression that the files should be copied by the javadoc tool 
itself, so this does not seem like a maven issue.

Maybe you could file an issue in Jira?

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Réf. : Re: new idea on maven usage?

[Rafal Krzewski]

Dalibor Topic wrote:

> I'm not arguing that it doesn't make sense in *all* contexts, I'm
> arguing that it's not a *silver bullet* in all contexts. 

Who told you that Maven is a silver bullet in all contexts?

> My impression
> is that there is a lot of (rightful! it's a cool piece of software)
> excitement, but little discussion of limitations of the new idea, so I'm
> playing an advocatus diaboli in this case ;)

... using massive amounts of bandwidth, and pissing the hell out of
certain people.

My advice is that you should start a project concerned with running Java
software using libraries managed with platform specifc package managers
, state your cause there, and go on discussing this with the people that
are interested. What you are doing now is an abuse of Maven mailing list
 IMO.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: new idea on maven usage?

[Rafal Krzewski]

Dalibor Topic wrote:

> But this is not the proper forum to discuss package management systems.
> The thread is about using maven for package management, and I'm arguing
> that it's not suited for it.

Dude, you keep missing the point! Maven *is not* and does not *pose*
itself to be a package management system!

It is a tool to build java libraries. And to document them. It is not
concerned with the fact of the resulting library being specific to a
single platform/architecture or general.

Second, it allows assembling libraries into applications (war, ear,
uber-jar etc). I guess you can compare such an application to a
statically linked C programm.

Chances are such application is not porable across some of the platforms
in existence. It does support safe and easy replacement of bits that
have been released with security fixes, or are available optimized in a
platform specific manner. You have a better chance that with statically
built C executable, but still you can break the application not knowing it.

This may be considered unfortunate, but it's not Maven's mission to
provide remedy for this situation. There is demand in Java community for
statically assembled applications, and Maven meets this demand.

I'd certainly love to see Maven running on as many platforms as
possible, and being as much platform agnostic in the way it operates as
it is possible.

regards,
R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: / /OREF:CPT95AB9 Project>Dependecies Newbie question

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:

> I actually consider this an unnecessary restriction. You should be
> able to specify dependencies without forcing a naming convention
> where version numbers are applied. You can use the .properties files
> to get round this but you lose the inheritance benefits , I believe
> (is this changing in later versions) Flexibility is important.

Maven project is about setting guidelines for project development. A
project that conforms to those guidelines is easy to comprehend and
maintain.

The Maven build tool is an important secondary pupropse. It helps to
develop projects that conform to the guidelines. If you don't want to
use the guidelines, but still use the build tool - you are on your own.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: / /OREF:CPT95AB9 Project>Dependecies Newbie question

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:

> Is the following snippet a valid dependency?
> 
> 
>   sailing-schedules
>   SailingSchedulesUtils
> 
> 
> For this dependency, I will not be providing an artifact version.
> So I wish to define the jar file name that resides in
> $MAVEN_REP/sailing-schedules/jars/ named SailingSchedulesUtils.jar
> as apose to something like this:

In Maven, every artifact in the repository has a version. Trying to
circumvert that will give you more headache that it is worth.
Certain artifact are have their versions removed when they are copied
out of the repository, but this is really an uncommon case.
OTOH project dependencies always specify a version. Your options where
are: just give your artifact an arbitrary version tag (1.0 seems a nice
choice), or use the special tag SNAPSHOT.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: User input for Continuum

[Rafal Krzewski]

Jason van Zyl wrote:
> Howdy,
> 
> I have Continuum up and running using the new maven-scm stuff and the
> new maven components so I wanted to get some input on how people would
> like to use it. All the information required for checking out and
> building are contained within the POM so how would you like to be able
> to use Continuum? By this I mean how would you like to be able to
> register projects to be built?

> o web interface to register an url or path

This seems to be easiest option to start with, because web browser is
the commodity client application. I may be a bit biased here, because
web interfaces is a big part of what I've been doing for past 3 years...

Other thing that I'd love is an eclipse plugin, that would feature a
view for browsing build messages, and would pop up message boxes on
a failed build. I can't afford to volunteer to write one, what makes
me sad. This is life, I guess...

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Style of generated site

[Rafal Krzewski]

Jörg Schaible wrote:

> with the current version of 1.0-rc2 (from CVS) and all plugins built
> fom CVS, I had to notice that the style of new generated sites differ
> a lot. I had previsouly used properties mensioned in the
> xdoc-plugin-docs to adjust colors to our companies' CI, but they are
> not respected with the new style anymore. How can I return to the
> previous style? And where can I create such a complete new style on
> my own?

Create xdocs/style/project.css and work from here. It's much more
powerful and flexible than the eariler peorperties approach.

R.

Create xdocs/style/project.css and work from here. It's much more
powerful and flexible than the eariler peorperties approach.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Protected Repository

[Rafal Krzewski]

Jason van Zyl wrote:

> I added support for Mike Cannon-Brooks for a password protected
> repository but I don't think it ever got tested.
> 
> Just looking at the code it looks like I added support for
> 
> http://username:[EMAIL PROTECTED]

I can confirm that it works correctly - have been using this for
a while a few months back.

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependency issues for junit tests [brain dump]

[Rafal Krzewski]

Lester Ward wrote:

> I totally disagree. There are two flavors of "type" and they mix. One (which
> I'll call "type") answers the question "what is this thing?". Possible
> values are .jar, .war, etc. This already exists in Maven. The other (which I
> call "scope") answers the question "how is this used?". Conceptually, values
> would be "runtime", "compile time", "test time". Unlike the "type", the
> "scope" values are not mutually exclusive; they would be or'd together. Part
> of this concept exists already in maven with the various *.bundle properties
> (e.g. war.bundle), which indicate that a dependency should be included in
> one kind of runtime artifact.
> 
> Most dependencies will have all three scopes, as they do now. It is unlikely
> that "runtime" would ever be used by itself, but the other two would.
> Dependencies of "compile time" only would be those where the dependency is
> already included in the runtime platform. This would include activation.jar
> and often would include mail.jar, j2ee.jar, etc. Another (very important)
> type of "compile time" dependency is a dependency that is used by the Maven
> code. If, for example, your maven.xml contains taskdefs, the jar to which
> you are linking must currently be in the classpath.
> 
> Dependencies of "test time" would be anything used by the testing process
> that is not released. Such things are usually test drivers or reporters of
> some kind.

Very good decomposition of the problem. I fully agree.

Dependency type space has (at least) two dimensions and collapsing them
to one yields silly results.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven - AntHill

[Rafal Krzewski]

Euan Guttridge wrote:
> Hi,
> 
> On the 28/8 Rafal Krzewski replied to the thread "Getting Source from CVS".
> Rafal mentioned there are plans to create CI features similar to AntHill for
> Maven. If this has progressed please let me know. Otherwise I will happily
> setup an AntHill/Maven system..

Your best be is to stick with AntHill or CruiseControl integration.
Intrisinc CI support is definetely a post 1.0 feature, that is not going
to be available in the next few months.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: plugin:uninstall

[Rafal Krzewski]

Christian Andersson wrote:

> and I still think a plugin:uninstall would work even if there was some
> plugins messed up, since the plugin:uninstall would depend on no other
> goals...  unless ofcourse if the messed up plugin is a preGoal to the
> plugin:uninstall goal...  but I doubt that would ever happen.

What happens if a plugin's plugin.jelly contains malformed xml markup?
I think the PluginManager loads/parses the plugin on startup, which in
effect makes maven fail on startup in such case?

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: plugin:uninstall

[Rafal Krzewski]

Brett Porter wrote:

> The manual process is
> rm $MAVEN_HOME/plugins/groupId-pluginId-version.jar
> The uninstall would be
> maven -DpluginId=pluginId -DgroupId=maven -Dversion=version plugin:uninstall
> 
> The first one is shorter :)

Plus, you can run the first one when your maven runtime is completly
messed up (for example by an invalid plugin!), but the other one
requires the runtime to be at least a bit functional...

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jelly: ${empty(pom.repository.url)} doesn't work

[Rafal Krzewski]

Rafal Krzewski wrote:

> The other thing is why empty() returns false even if the actual value
> of the expression is null? I don't know why. I wasn't able to find
> any reference of the jexl syntax...

OK, I've found the ultimate jexl syntax reference, at least for those
who can read JavaCC grammars:

http://cvs.apache.org/viewcvs/jakarta-commons/jexl/src/java/org/apache/commons/jexl/parser/Parser.jjt?rev=HEAD

For the details how things get evaluated, see the AST*.java files in the
parser package, the actual logic is in the execute() / value() methods.

Hope that helps a bit...

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jelly: ${empty(pom.repository.url)} doesn't work

[Rafal Krzewski]

Alexey Krasnoriadtsev wrote:
> Yes for my own scripting I won't use dot in the var names. But, maven
> uses dots extensibly, i.e. pom.foo.foo
> And here is the line in xdoc-plugin/site.jsl: 195  test="${!empty(pom.repository.url)}"> 
> that doesn't work, and it always adds a link in the navigation, even
> though the page doesn't exists.

Dots in this context work, because pom.repository.url is not a name of a
variable - it is an expression! The original variable is 'pom', then
'repository' property is read from it bean-ways, and then 'url' property
is read from the previous result.

The other thing is why empty() returns false even if the actual value
of the expression is null? I don't know why. I wasn't able to find
any reference of the jexl syntax...

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple Source Paths

[Rafal Krzewski]

Steve Garcia wrote:
> Yup, I feared that almost all of Maven's plugins rely on a single source
> directory.

It is a conscious design decision, not an unintended mis-feature.

> I guess another solution is to move all of the source to a single temp
> directory before any plugins are executed.

Yet another one, but much more Mavenish is to break down your project
into multiple smaller projects connected with a network of dependencies.
Each of these will have a directory for sources and tests.

I know that this approach may not be easy to adopt for certain projects
especially in corporate enviroments.

> Are there any suggestions or enhancement requests to require plugins to
> handle multiple source directories?  If that can be a requirement, then this
> idea wouldn't seem difficult to deal with.

Proposals to enhance plugins in this way are very unlikely to be
accepted (see above).

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: available tag within loop

[Rafal Krzewski]

Nathan Coast wrote:

Hi,

Apologies if this is a duplicate, I think I posted this yesterday but it 
doesn't seem to have reached the list.

I'm having problems using ant:available within a loop.


   
   
   
   
   . do something
   
   

If the available test fails to locate the file, the value of the 
property is unchanged.  So when a file is located, all subsequent loops 
the property junitejb.test.jar.available is true.

I tried resetting the property to "" but then the var doesn't seem to 
get set to true if a file is located in subsequent loops.
Ant properties can be set once only, so  tag just won't 
cut it here. You need to take a look at the jelly tag libraries for a 
tag doing a similar thing. Alternatively you could instantiate 
java.io.File object programatically using jelly:core tags, and call 
${file.exists()} in the  test.

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: errors in webpage

[Rafal Krzewski]

Christian Andersson wrote:
> in the page
> http://maven.apache.org/reference/project-descriptor.html
> in the section about pomVersion it referes to an updating page
> http://maven.apache.org/reference/updating.html
> 
> which does not exist..
> 
> should these "simple" errors be reported to jira? or is it just
> neceserry to report it in here?

Reporting in Jira is the best way of making sure things don't get
forgotten. If the developers find your report irrelevant they'll
close it with no fuss. It's better to report to much that too
little.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Controlling snapshot or not in POM or properties?

[Rafal Krzewski]

Craig S. Cottingham wrote:

> Is there something I can add to project.xml or project.properties that
> will control whether or not a snapshot is generated? Does it help that
> I've adopted the convention of ending the value of the currentVersion
> tag in project.xml with "-dev" for those jars in flux, while those which
> are frozen will not end with "-dev"?

There's nothing in Maven to deal with this for you, but I think this is
a good idea. Would you please file a Jira issue for it?

R.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: rmi generation

[Rafal Krzewski]

Christian Andersson wrote:
> Hi there, just wnated to tell you that I now have managed to create a
> first generation alpha version of an rmicomiler for maven.
> 
> the rmicompiler searches the compiled classes in the project and search
> for files classes that extends the java.rmi.Remote interface.
> after that it passes all of these files back to the jelly script where I
> use the ant:rmic task to compile the files..

Please keep us posted. Maven is currently not accepting new plugin
submissions, because it was decided that non-core plugins will be hosted
separately. Soon after 1.0 release the Maven team will be setting up a
repository for those plugins. If your plugin is ready before that
happens, you can submit it to http://maven-plugins.sf.net/.

Happy hacking,
R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Usability issues & general ranting

[Rafal Krzewski]

Howard M. Lewis Ship wrote:
> Windows XP prof, Sun Jdk 1.4, 512MB ram, Pentium 4

I'm on Linux, the rest basicly the same, so the OS is probably the main
difference. This is still strange though, because some of the core
developers are using windwos IIRC.

What specific problems you are having, could you post the error messages?

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Usability issues & general ranting

[Rafal Krzewski]

Howard M. Lewis Ship wrote:

> I still haven't been able to break through on Tapestry, which needs
> to be a multiproject.  I'm waiting for the RC binaries (because I've
> never been able to build Maven from source) before I try again.

What platform are you on? Bootstraping Maven from CVS works flawlessly
for me most of the time.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Usability issues & general ranting

[Rafal Krzewski]

> I've basically given up on Maven for the time being. My impression
> of the state of the project is that it should not be in beta, the
> quality is more like that of an alpha-status project.

We didn't force you to try Maven. It is regrettable that you wasted
some of your time, but this fact does not entitle you to waste our
time by flaming us this way.

This is a community effort. There is plenty of ways you could contribute
to it, but the sort of criticism you are giving is certainly not one
of them.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ear assembly

[Rafal Krzewski]

Nathan Coast wrote:

> 1) use reactor to build all of the constituent jars, wars, ejb-jars.
> Copy these files to the ear assembly directory and then use the ear plugin.
> 
> 2) use reactor to build all of the constituent jars, wars, ejb-jars etc.
> Install these components into the local repo using the multi-project
> plugin.  Declare all of the dependencies for the ear within the ear
> project.xml,  build the ear using the ear plugin.

AFAICT 2) is the official recommended practice.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any reason we have to resolve dependencies all the time?

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
> How many different s do you see.

build, test & runtime is what's needed by most of the plugins
(for example war.bundle and friends are in essence runtime
dependencies). Still, we may want to let this set be open -
allow arbitrary text inside ,  or whatever
we choose it to be, and the accessor method would be
Project.getDependencies(String type) This way plugin authors
will be able to create custom dependency types when they
need it. The downside is this feature is likely to be abused...

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any reason we have to resolve dependencies all the time?

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
> How many different s do you see.

build, test & runtime is what's needed by most of the plugins
(for example war.bundle and friends are in essence runtime
dependencies). Still, we may want to let this set be open -
allow arbitrary text inside ,  or whatever
we choose it to be, and the accessor method would be
Project.getDependencies(String type) This way plugin authors
will be able to create custom dependency types when they
need it. The downside is this feature is likely to be abused...

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there any reason we have to resolve dependencies all the time?

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
> Yes, resolving dependencies all the time is a PITA.
> 
> What's your suggested alternative?
> 
> Do plugins declare whether they need the dependencies?
> Some other method of us guessing?

Lazy evaluation I guess. Checking dependencies could be delayed
until the moment something acually calls Project.getDependencies()

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: simian report failure

[Rafal Krzewski]

Dominik Dahlem wrote:
> I had a look at the sources shipped with the plugin. The file
> SimianLog.java appears to have a bug (at least in my scenario). The
> simian.log file contains the line "Processed a total of 123 lines in 4
> files". The StringTokenizer created for this line expects the 10th token
> to contain the number of files being processed. Instead it is the 8th
> one. I deleted lines 234/235 (which just jump over tokens) and all is
> working now.

Would you please file an issue in Jira, and attach the patch?

Thanks,
R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Integrate jaxrpc as dependency

[Rafal Krzewski]

Markus Pscheidt wrote:

> The problem is that there seems to be no download place available for
> jaxrpc.jar which I could use in the URL parameter of the dependency
> element. The place at ibiblio does not contain jar files for jaxrpc (
> http://www.ibiblio.org/maven/jaxrpc/ ).

Sun's licensig policy does not allow ibiblio (and others) to
redistribute their software. A solution (legal+technical) is being
worked on to assist Maven users in dowloading necessary jars fulfilling
Sun's policy (which is presenting full license text to the user and his/
her explicit acceptance of it).

> Of course, one solution is to copy jaxrpc.jar to
> $MAVEN_REPO_LOCAL/jaxrpc/jars/jaxrpc-1.0.jar, but this is not very elegant.

Until the aforementioned solution is complete this is exactly the way
you should solve your problem.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: Getting source from CVS

[Rafal Krzewski]

Eran Chinthaka wrote:

>  Any body is here to help me 

Plese keep in mind, this is a volunteer effort. People are *not* getting
paid to develop this software, nor to answer your mail. Being polite
greatly increases your chances of getting help.

As for your question - no. Maven does not provide contiuous integration
(aka autobuilding) funcitonality. It can be integrated into CI systems
like Anthill or Centipede though. People described their solutions for
doing this on the list, please search the archives.

There is also a plan for building this functionality into Maven, but
no dates have been set and no requirements analysis / specification
exitsts that I know of.


R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: includeProjectDocumentation in multiproject plugin?

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
What should happen is this:
sub projects should inherit main and be able to override them.
I don't think so. Inheriting project.xml / maven.xml (but not
project properties, see MAVEN-37 - our longest standing bug)
happens when a project extends another. Main project - sub
project relationship is something completly different and does
not involve iheriting settings. Incidentally, some people may
decide use the main project as the vehicle for the settings shared
by the sub projects, and use inheritance in conjunction with
multiproject, but this is by no means a general rule.
R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: adding dependency to a jar in the sdk

[Rafal Krzewski]

Marco Herrn wrote:

> I am using the $JAVA_HOME/lib/tools.jar in a project. Unfortunately I found
> no way of telling maven to set a dependency on this. What is important here
> is, that it should refer to the $JAVA_HOME environment variable. Is there a
> way of getting this dependency handled by maven?

The maven way of solving this is copying $JAVA_HOME/tools.jar to
$MAVEN_REPO_LOCAL/jdk/jars/tools-1.4.2.jar and then depending on

jdk
tools
1.4.2

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: Re: Jelly if problem

[Rafal Krzewski]

Alwyn Schoeman wrote:
> Hi,
> 
> Could you please paste his message into a new mail.
> 
> People who do not use outlook cannot read outlook attached messages.

Mozilla 1.5a shows the attachment withot any problems. Here it goes:

Subject:
Re: Jelly if problem
From:
Evan Koffler <[EMAIL PROTECTED]>
Date:
Mon, 25 Aug 2003 12:22:18 -0500
To:
[EMAIL PROTECTED]

I'm not much of an expert so I expect someone else more knowledgable to
respond (which is why this is going directly to you).

Short answer: use _ instead of . in your variable names.

Jelly is interpreting the j:if and looking for object idl, to have
property already which has property generated. Or equivalent to:
idl.getAlready().getGenerated(). Changing the . to _ will make it more
like a Java variable idl_already_generated.

Evan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: pom directory in maven repository

[Rafal Krzewski]

Norbert Pabiś wrote:
> Does anybody know what is pom directory in maven repository for?
> On ibiblio it is always empty (at least in this projects I was
> interested in).

project.xml files are intended to be deployed in there so that things
like automatic discovery of project dependencies are possible in the
future.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jcoverage plugin

[Rafal Krzewski]

Dominik Dahlem wrote:

> Instead of working with clover I'm using jcoverage which is available
>  under GPL license. I implemented a plugin for jcoverage. Can someone
> tell me, whether there is already a plugin available? If not, I'd
> like to contribute mine. In this case can somebody give me a hint how
> to do it?

There's a sourceforge project hosting plugins that are
license-incompatible with Maven proper:

http://maven-plugins.sourceforge.net/

Write to stephanemor(at)users.sourceforge.net for details on
contributing.

Happy hacking,
R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Unknown goal "clean:clean" in a multiproject environment

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
> You've got the top level project included in the set of directories that 
> multiproject is processing.
> 
> This is not supported ATM.

My guess is that is caused by a bug in Werkz, or in the way Maven uses
them. When you try to run goals on a project for the second time in a
maven run it complains about them being undefined, instead of just
skipping them silently (because they are done).

For the time being, the multiproject plugin might be improved by
extracting the bit that iterates over projects and checks for a
duplicaing top level project in sub project into a reusable tag
(it also sets the 'reactorProjects' variable).

I'll take a look at this later.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: goal dependencies

[Rafal Krzewski]

Simon Matic Langford wrote:
> is it possible to make a goal depend on another goal, similar to ant
> targets?
> 
> I can put an  tag in my goal, but that causes the goal to
> be run, regardless
> of whether or not it has been run before, and some goals do their thing
> everytime, regardless
> of whether they've been run, which I'm sure is sometimes necessary (eg
> clover needs test:test to
> run again because it instruments the code). Unless goals (and plugins)
> should check better
> to see if they need to run?


...


R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: howto call ant task from maven.xml

[Rafal Krzewski]

Roland Berger wrote:
> Hi all
> 
> Everywhere I can read that it is easy to call an ant target from maven.xml
> but after all I did not find an example.
> I tried it the following way:
> 
> 
> 
>classname="com.signsoft.ibo.enhancer.Main"
> classpathref="project.class.path">  
> 
>   
> 
> 
> All I get is:
> 
> Fatal Error [line 3, row 143]: The prefix "ant" for element "ant:java" is
> not bound.
> 
> Thank you for any example how to do it better.



  

  

  


R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven and missing jelly jars

[Rafal Krzewski]

John Farrell wrote:

> Maven itself can't know about all jars, but the developers who make the 
> dependencies know. I suggest that (a) maven get a feature which allows it to 
> retrieve from the repository information about an undownloadable jar, and (b) 
> developers who depend on such jars put such information in the repository. 
> All it has to be is a short note saying "Sun does not allow this jar to be 
> distributed automatically. Please go to this page to get it." Of course, no 
> rush, I would like to see some bugs fixed first, but this would be a whole 
> lot nicer than "no such jar rrrgggh.'

Maven has most of the information needed to print out an polite message.
 has  element, which is good enough if the jar is
available in the web directly. It's a bit more complicated if the user
needs to accept a licence before the actual download is possible.
Of the top of my head:

  j2ee
  1.3
  jar
  http://java.sun.com/j2ee/sdk_1.3
  You need to accept the license and download J2EE
distiribution for your platform. Install it and copy j2ee.jar found in
the lib/ directory of the installed distribution into the following
location: ${localRepoLocation}


${localRepoLocation} bit is easy, because it can be derived from
maven.local.repo, type, id and version.

> BTW, how does Maven depend on jelly when jelly is in such a sorry state? 

Jelly runtime and core tag libraries are healthy enough for Maven to
use. We don't care much about other tag libraries let alone examples...

> Is there an internal release which is not available to the public at
> large?

Not at all. What good would that be?

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven beta 10 repository directory

[Rafal Krzewski]

S. Radhakrishnan wrote:

> Now, building the checkstyle report using Maven 10, it gives me the
> following exception.
> 
> com.puppycrawl.tools.checkstyle.api.CheckstyleException: unable to parse
> /home/intranet/cvs/metapa/adr/my-checkstyle.properties - Premature end of
> file.:-1:-1
> 
> however,it was working fine with Maven 9. Is there any other special
> consideration for Maven 10??

Beta 10 uses newer version of checkstyle, 1.2 if my memory suits me.
You need to convert your rules file into new xml format. See checkstyle
documentation for details.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: project/properties and multiproject inheritance broken?

[Rafal Krzewski]

Kevin Ross wrote:
> in a bid for the longest running single user thread
> 
> 1.  CSS style properties work on parent and sub projects
> 2.  Normal properties are not inherited.
> 
> How does property inheritance work?  What is the best practice to share
> properties across projects?

project.properties / build.properties are NOT inherited. It's a long
standing bug, that everyone wants fixed. Jason's last refactoring has
landed and HEAD has stabilized enough that it's possible to build
after bootstraping. Seems like a good moment to take a swing at this
issue...

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Two requests

[Rafal Krzewski]

Joshua Spiewak wrote:

I was wondering if the latest Jakarta Taglibs standard/jstl jars 
(version 1.0.3) could be uploaded to ibiblio.
The procedure of upload requests is described in Maven docs, can't
remember where though. Try you luck with site search.
Also, is there any plan for site:deploy to be able to use ftp?  My web 
host company does not give me shell access, so I will either need to ftp 
by hand, or if no one is currently working on ftp perhaps I can take it up.
FTP and few other deployment methods are imlemented in the 'artifact' 
plugin. Plugging them into 'jar' and site 'plugins' should be really 
straightforward task, but Michal (the author of artifact plugin) decided
(or was told to) to wait until the deployers get some amount of testing
through war/ear plugins. I don't know how long are these tests about
to last. AFAICT no problems with war/ear deployments were reported
lately - either because they work perfecly, or nobody uses them.

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jmeter/Maven integration

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
> LGPL jars and GPL jars are not allowed to be distributed by ASF projects.

But it's the ibiblio.org who is storing distributing jars for us, and
AFAIK they have no problem with GPL/LGPL. The real question IMO is:
Is code that depends on (uses) GPL/LGPL libraries allowed to go into
ASF repositories? How does copile & link-time depending on a library
affecting 'derived work' status of source code? I'm no expert on the
issue but I think that linking against LGPL library does not make your
code LGPL, but linking against GPL library does.

Can someone more experineced in this explain?

R.

PS. I know that sticking with ASF license is the best approach for
staying out of trouble.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: master property file

[Rafal Krzewski]

Dominik Dahlem wrote:

> This master project property file can be kept in source
> control and provides a single location for settings shared
> among sub-projects. Imagine you have 50 sub-projects and each
> of them contains a project properties file with settings
> which could well be shared. It's maintenance hell, if properties
> are likely to change.

This is a known problem, everyone wants that fixed. Unfortunately
it was very hard to do proprerly within the internal data model
Maven was using. Right now Jason is in the middle of a major refactoring
of the internals, and I hope that property inheritance will be among of
the the things it will make easy/possible.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jmeter/Maven integration

[Rafal Krzewski]

[EMAIL PROTECTED] wrote:
> Siegfried,
> 
> that's a good idea. Do u have any experience with it? I'd love to be able 
> to easily generate charts etc from raw data via maven.

There is a library called JFreeChart that is able of drawing all sorts
of funky graphs, charts and diagrams. I believe it is also able to save
them in a variety of file formats. Not sure about the license though.

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [HOWTO] New feature: filtering

[Rafal Krzewski]

Brett Porter wrote:
> Submitted under a nice round number of MAVEN-600 :)

Suppose we should consider throwing a party @ MAVEN-1000 :-D

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Modifying the xdocs template files

[Rafal Krzewski]

Jefferson K. French wrote:
> Is it possible to override any of the templates in the xdocs plugin,
> besides editing the installed file? I want to change the wording on
> some of the pages, rather than the colors. For instance, since our
> project does not allow anonymous CVS access, I'd like to remove the
> section about anonymous access from cvs-usage.html. I've tried setting
> various properties in an attempt to use different plug-resources or
> templates, but so far to no avail.
> 
> I thought this would be something others would have asked, but I
> couldn't find an answer in the archives. Either others don't want to
> do this, or I'm completely missing something!

I don't know if xdoc plugin supports template/stylesheet (I mean xml
transformation stylesheet, not the css) overriding. If the documentation
doesn't say anything about it you can look at the sources of the plugin.

As for CVS instruction page, take a look at issue MAVEN-595. I hope to
get it checked in soon.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Site/Multiproject plugins

[Rafal Krzewski]

Andy Jefferson wrote:

The plugin-generated main project pages automatically gets links down to
the sub-projects via the multiproject plugin, showing the sub-projects
in the side navigation bar. This menu above adds links back from the
sub-projects to the main in the side navigation bar (would be nice for
the multiproject to add this itself in a future release)
The plugin is able to generate links for you, but the usage of this
feature is not really straightforward ATM. You have two options
1) If you don't have any custom xdocs in your top level project delete
the navigation.xml file - you'll get one containting 'Projects' menu
with linkst to the subprojects, and well known 'Project docmentation'
for the top level project.
2) If you have the xdocs in the top level project you must provide a
velocity template for generating the navigation with subproject links.
You need to grab one of the files from
http://cvs.apache.org/viewcvs/maven/src/plugins-build/multiproject/src/plugin-resources/templates/
and fill them in with your custom links. You need to put your copy into
the ${basedir}/multiproject/navigation.xml location. I personally think
it should better be ${basedir}/xdocs/multiproject-navigation.xml, I'm
going to file an issue for that.
a). Personally I think that in the multiproject plugin, it would be
better to use project 'id' rather than 'name' in the generation of
directories under "docs/multiproject". The 'name' can be much longer,
whereas the id will be more concise and less likely to change - so for
example in my example above I could have just put 'App' instead of 'The
Application'.
See http://jira.codehaus.org/secure/ViewIssue.jspa?id=11325

b). The generation of the site seems to have changed in beta 10 (note
definite on this), but if i run a "maven site:generate" it does the
compile AFTER the javadoc. The only problem here is that I use xdoclet
to generate a series of interface classes, and hence these don't make
their way into the Javadoc since they are generated after the javadoc
(and hence javadoc complains about all sorts of missing classes). Seems
logical to change this so that it does a compile first of all ... any
problems with doing this ?
I've never used xdoclet but I think it's a major issue for anyone who
is. Consider filing a bug report. As a stop-gap solution you should be
able to fix it in your maven.xml with a  tag.
c). How do I get anything to appear under the "Project Info"->"Issue
Tracking" link ? Is there a section in project.xml for this ? (couldnt
find one).

   
   the url

d). Can I get rid of the "Development Process" link ? (I can change the
URL I know, but I want to remove it totally :-)).
I see you've filed a bug for that. If noone picks it up, I'd recommend
approaching Ben or d'Ion personally - they have a lot of experience with
site generation stuff.
[e. had to omit the main project from the multiproject generation
because of the bug spotted by Rafal Krzewski. - will be perfect when we
can enable this again, because at the moment it is ignoring generating
my own documentation for the top-level project].
Your documentation is processed. The issue was showing up if you told
maven to process it twice: as the super project, and one of the sub 
projects at the same time. Just look into target/docs and find the
generated .html files. The problem is that links to the won't show up
unless you provide ${basedir}/multiproject/navigation.xml file (see
above).

I have another idea for solving the issue of navigation generation.
Multiproject plugin could add a  tag to the 
navigation.xml schema. The menu would be written to 
target/generated-xdocs/subprojects-menu.xml and itegrated in the proper 
place by the site's stylesheet in the xdoc plugin. I think this would
be a much cleaner solution that what we have now. I'll look into
implementing this, but I'll need to learn more about manipulating 
xml/DOM under jelly so this will take some time, unless someone more
experienced steps in to help.

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: - ZIP dependencies -

[Rafal Krzewski]

Velu VELOUTE wrote:
I renamed it to jar. Isn't that an option for you?

incze

Sure, it could also be a trick for now. But in fact, what is the use of 
that jars subdirectories in the maven repository and the  element 
in the project.xml if, at last, each dependency has to be a .jar file ?
I look at this from a different angle. .jar is a commonly accepted 
extension for class libraries. .ejb files are also class libraries --
you need to put them into the classpath to use them. OTOH .zip is
a general purpose format, often used to deliver soruce/binary
distributions of software. Despite the fact of having the same
file format as .jar, it's no more related with java classpath than say
.fred extension. Would you like maven to support class libraries
named .fred? :-)

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WAR file naming

[Rafal Krzewski]

Andy Jefferson wrote:
>>>Actually if you are packaging your war into an ear, you can specify the
>>>context, or if you have jboss you can put a jboss-web.xml in your
>>>WEB-INF and specify it there.
>>
>>Can you do this with Tomact :P?

Setting the context name is trivial with Tomcat. In version 3.x you can
do it in the server.xml file, using  tag:



In 4.1.x it's even easier, you don't need to fuss around wiht server.xml
Instead of dropping the war into $TOMCAT_HOME/webapps you put in a
a little xml file in there, containing the  tag only.

I don't know if maven j2ee support plugins provide war deployment goals,
but if so I imagine that this file could be generated on the fly, based
on the war's final name, TOMCAT_HOME and context name configured in
project.properties.

I'd vote for generating versioned war artifacts as a policy, and people
who are too lazy to read their's servers docs can still make an
unversioned copy of the war in their maven.xml

R.

PS. Now I recall that Tomcat 3.x also had some way of declaring contexts
outside server.xml, but the files were looked up in $TOMCAT_HOME/conf.
Don't remeber the syntax though.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "multiproject" Plugin

[Rafal Krzewski]

Andy Jefferson wrote:
> Hi all,
> 
> anyone used the multiproject plugin successfully ?
> 
> I have a hierarchy of projects
> 
> my_project/
> my_project/jar_project/
> my_project/war_project/
> my_project/ear_project/
> 
> In my project.xml at the top level I have registered several reports
> including checkstyle, javadoc, license.
> 
> I then run 'maven multiproject' :


>  Goal [xdoc:register-reports] has no action definition.
> Total time: 3 minutes 42 seconds

I've run into that just yesterday. See
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-574

Make sure that top level project is excluded from multiproject
processing, because this is the case of the exception. It should be
docummented, and the error should be interecepted and reported
in an understandable way.

The site (incl. reports) for the top level project will be still
generated when it is excluded. On the downside, the navigation.xml
that you may have in your top level project's xdocs is ignored
completly, so only the reports are visible in that project's docs.
I believe that this is fixable - so stay tuned for improvements.

Good luck,
R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: own checkstyle

[Rafal Krzewski]

Kristine Weissbarth wrote:
> hi,
> 
> how can I integrate my own checkstyle.xml to be checked during the
> checkstyle report. What do I have to do with my checks_project.xml? 
> I found out that the standart checks are situated in
> maven-1.0-beta-9/plugins/maven-checkstyle-plugin-2.0-SNAPSHOT.jar but
> how can I intergate my own check?

Set the following property:

maven.checkstyle.properties=${basedir}/checkstyle.xml

You could find this out yourself easily reading checkstyle plugin's
plugin.jelly file.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eclipse & Maven project directory structure dilemma

[Rafal Krzewski]

Kumar, Vaidhyanatha K. wrote:
> The existing project looks like this
> ProjectA  -- project_a.war
> mod1 --mod1.jar
> src/java
> web
> mod2 -- mod2.jar
> src/java
> web
> mod3
> ...
> ..

> To use maven & eclipse, Should be creating project & subprojects and
> convert them to eclipse project ??  Since mod1, mod2 etc are
> identical in the directory structure , I think it is a overkill to
> create various subprojects. The source code mod1, mod2 etc are in
> Clearcase. How do I move forward? Thanks for your help. 

True enough, there is a dilemma, and there is no obvious solution.

The Eclipse way is to set up each module as a separate project,
declare dependencies between them using Eclipse UI. This lets you
use Eclipse for daily edit-copile cycle. The downside of this approach
that you need fairly complicated custom Maven configuration for
assembling your application and for generating reports on the
whole codebase.

The Maven way is to set up a single elicpse project with subdirectories
for each module and use simple and standard reactored build. At the
same time you will need a fairly complicated Eclipse build path setup
to take advantage of the builtin incremental compiler, and other
features. Note that in a reactored build you'll get separate reports
for each module, unless you come up with a non-standard Maven configuration.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Artifact plugin

[Rafal Krzewski]

Hello,

this is mostly to Michal:

1) Any chance to use artifact plugin in the jar plugin soon?

2) Currently a plugin called 'deploy' exists, that has a single goal,
for deplyoing the pom to the repo. I believe that this goal should go
into the 'pom' plugin. The 'deploy' plugin could be nuke then. I think
it might be a good idea to reuse this name and rename 'artifact' plugin
to it. What do you think?

3) I think there's an error in DefaultArtifactDeployer.java, line 248
"maven.central.directory" should probably be "maven.repo.central.directory".

Greetings,
R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: entities in generated HTML from xdoc-plugin

[Rafal Krzewski]

Kai Runte wrote:
Hi,

maybe this is the wrong list to ask, apologies if yes.
Currently I working on a site.jsl script for creating webpages in the 
look-and-feel of our internal website. For some obscure layout reasons I 
need to have a   entity in the target HTML document, but utterly 
failed in getting Jelly/JSL to do so.
If I try the following:

 

Maven bails out with:
BUILD FAILED
null:-1:-1:  Could not parse Jelly script
Did you try escaping the & charcter as & entity in the jelly source?
I think it will get written as & in the target document:

 

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How adaptable is Maven's version system?

[Rafal Krzewski]

Christian Clausen wrote:
> I suddenly realize that we use the two different styles of snapshot versions:
> You're talking about timestamped jars created with jar:deploy-snapshot while I'm
> talking about jars of a project with version x.y-SNAPSHOT (in project.xml) and
> deployed with jar:deploy. When using the style of snapshot version that I use,
> it's (of course) possible to have multiple multiple "snapshot versions" (one for
> each branch).

I'm very sorry for the confusion I've caused. I was not aware that
versions named SNAPSHOT are considered snapshots by the
dependency verifier - I was positive that verbatim 'SNAPSHOT' version
triggers the check-on-each-build processing.

It's generally a good thing that snapshot per version is supported,
and this is the direction that I hope maven is going to take, but
the implementation is at best incomplete ATM. In the future,
:deploy-snapshot should retain the version information
on the timestamped files (+ in the associated metadata file(s)),
and dependency specification format should be changed in a way that
makes in possible to state a 'snapshot' dependency leaving the
version attribute intact.

> In your case, there is another option for allowing multiple
> snapshots, if you don't like to change the artifact names to
> -: Use different groups for different branches. So if 
> is your group, then your branched group could be named -.

True enough, it's possible to get this behaviour this way, but I'd still
opt for artifact renaming -- you don't usually branch your organization
when you want to split your codebase into stabled & development
branches :-). I think of it this way - 'tomcat' group could deliver
tomcat-3, tomcat-4, and tomcat-5 artifacts, that are both legitimate
branches of the same product and should have distict 'snapshot'
versions.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How adaptable is Maven's version system?

[Rafal Krzewski]

Moretti, Luciano (MED) wrote:

> I was deploying distributions, not jars.  The jar:deploy-snapshot
> creates the sym links and the index file.

Ah, you run across another inconsistency in artifact handling. When
Michal is done with the war plugins artifact support, he'll probably
update other plugins so that all of this stuff works as expected.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How adaptable is Maven's version system?

[Rafal Krzewski]

Moretti, Luciano (MED) wrote:
> I hate to disagree, as I'm a complete Newbie, but as I asked the
> question, originally, I should comment on what I found-
> 
> When you do a dist:snapshot-deploy or a jar:snapshot-deploy the archive
> created has a timestamp on it (down to the Second it was created IIRC.)
> You can have multiple snapshots deployed (I've got multiple created at
> the moment)

Unless something is badly broken you should also get
artifact-SNAPSHOT.jar in the group directory, that is either a copy
of the timestamped jar that you've just deployed, or a symlink to that
file.

The term 'snapshot version' means the most recent of the 'timestamped
versions'. In the current setup this should always be available as
artifact-SNAPSHOT.jar file/symlink.

> I don't know how it works to pull the jar down, but I expect that it
> checks the date tag and pulls down the most recent.

Only artifact-SNAPSHOT.jar is checked/downloaded ATM. HTTP does not
support directory listings (web server do support listings, but it's
optional and not standarized) and FTP does not provide file timestamps,
so our best bet at discovering artifact versions is maintaining a
metadata file for each artifact in the group directory, that would
contain filename, timestamp and checksum for each deployed version of
the artifact.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How adaptable is Maven's version system?

[Rafal Krzewski]

Christian Clausen wrote:

> Sorry for not being explicit. I disagree with the statement "you need to put the
> name of the branch into the artifact name". In my example, the artifactId is the
> same in all branches.

With current maven, you can have only one snapshot version per artifact.
If you project has two branches that need separate snapshots, it must
deliver two distinct artifacts. There is no way around this, that I know
of. Therefore the easiest way of achieving the objective of having
distinct snaphost versions for both branches of your codebase is
delivering two artifacts named in - fashion.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How adaptable is Maven's version system?

[Rafal Krzewski]

Christian Clausen wrote:
> Quoting Rafal Krzewski <[EMAIL PROTECTED]>:
> 
> 
>>Moretti, Luciano (MED) wrote:
>>
>>>So how does the Snapshot resolving determine what is the latest version
>>>in the online repositories?
>>
>>AFAIK, you can have only one SNAPSHOT version per artifact. This means
>>that if you are developing two branches of your project in paralell,
>>and want to have SNAPSHOT versions for both of the branches, you need
>>to put the name of the branch into the artifact name:
>>
>>artifactId: myproject-1.0
>>versions: 1.0 1.1 SNAPSHOT (SNAPSHOT presumably is 1.2-dev)
> 
> I don't agree. The artifact id should be constant, and snapshot versions just
> end with "SNAPSHOT". In a development branch, versions should be named
> x.y-SNAPSHOT (development towards x.y.0.) In a production branch, versions
> should be x.y.z plus maybe x.y-SNAPSHOT.

I'm just telling you how things work in maven-b9 and upcoming manen-rc1,
 so I don't quite understand what you don't agree to :)

> Examples:
> 
> artifactId: myproject
> versions: 
> 
>   In development branch: 1.0-SNAPSHOT, 1.1-SNAPSHOT
>   In 1.0 branch: 1.0.0, 1.0.1, 1.0.2, ..., 1.0-SNAPSHOT
>   In 1.1 branch: 1.1.0, 1.1.1, 1.1.2, ..., 1.1-SNAPSHOT
> 
> When the 1.0 branch is created, the version of the development branch is changed
> to 1.1-SNAPSHOT, and the version of the 1.0 branch is changed to 1.0.0.

This is rather similar to what I've written further down in my message.
I hope things will work this way in maven-new.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: language modification

[Rafal Krzewski]

Kristine Weissbarth wrote:
> hi,
> 
> is there a possibility to set the language of the documentation and
> navigation which is generated by maven to another language than english?

At this moment Maven does not have site/report templates in languages
different that english, nor neccessary infrastrucure for provididing
such functionality.

Those will probably be added at some time in the future, but I suppose
this has a low priority because english is so widely accepted in the
software developers community around the world.

> I found a property 'maven.docs.outputencoding' but when I try to set it
> to german (in the following way: maven.docs.outputencoding = iso-8859-1)
> nothing changes. 
> Maybe it's not the right property or do I declarate it in a wrong way?

This property is useful when the POM or the generated reports need
character encoding different than the default ISO-8859-1 for example to
display deleloper names correctly.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven logo

[Rafal Krzewski]

Kristine Weissbarth wrote:
> Thanks, that's it!

It's not very polite to remove the logo completly - don't you think that
Jason and the rest of the gang deserve some credit for their work?

If you don like the red logo image, there are many other nicer looking
maven logos to choose from, take a look at the directory.
maven/src/plugins-build/xdoc/src/plugin-resources/images/logos
When you decide on one of those, put the following into your
project.properties:

maven.xdoc.poweredby.image=images/logos/

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How adaptable is Maven's version system?

[Rafal Krzewski]

Moretti, Luciano (MED) wrote:
> So how does the Snapshot resolving determine what is the latest version
> in the online repositories?

AFAIK, you can have only one SNAPSHOT version per artifact. This means
that if you are developing two branches of your project in paralell,
and want to have SNAPSHOT versions for both of the branches, you need
to put the name of the branch into the artifact name:

artifactId: myproject-1.0
versions: 1.0 1.1 SNAPSHOT (SNAPSHOT presumably is 1.2-dev)

artifactId: myproject-2.0
versions 2.0 SNAPSHOT (SNAPSHOT presumably is 2.1-dev)

As for future direction I would prefer the following scheme


  myproject
  1.2-dev
  


Where  creates a dependency hint that is picked up by the
resolver - it tells it that it should look for newest timestamped
version of myproject-1.2-dev. The release wizard would freeze such
dependency into:


  myproject
  1.2-dev-20030620.124616


Ensuring that the future builds will pick correct artifact.

R


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: POM and maven-new

[Rafal Krzewski]

Jason van Zyl wrote:

> We'll probably find there are more orthogonal sets of qualities as you
> put it. Whatever is more clear I'm fine with. To me the type is just
> another piece of information.

It's possible that more orthogonal qualities will show over time.
I think that it would be good to keep them visually separated in the
POM to make it more readeable to humans. I don't have strong opinion
on the internal representation though - if it's easier to keep all
the hinting information in single place it's OK with me.

>>Type determines the filename, and repository location of the artifact,
>>but does not affect the kind of processing the artifact will recieve.
> 
> Currently in maven-new it is the only thing that determines the kind of
> processing, but it won't stay like that.

I may be not up to date with maven-new internal, but I imaging this like
that: A plugin is invoked (because a goal defined by in was requested),
then it picks up a predefined set of dependencies and processes each
one in turn. The exact actions taken for the dependency may depend
on the dependency type of course (a tld is processed differently
than a jar by the war plugin for example).

>>Kind (class, nature?) determines in which of the productions you've
>>mentioned the artifact show up. 
> 
> 
> Artifact or anything else that is derived from a dependency.

I meant what set/collection the dependency shows up. I think that in
most contexts it makes little sense to extract information from each
dependency in turn and pile it up together. If you look at properties
declared per-dependency, consolidating them makes not sense.

>>because it's supposed to be specific
>>for the war plugin. I'd much rather have:
>>
>>war
> 
> 
> You mean defining a set of properties that are valid for use with the
> WAR plugin? Yup, that will be necessary for other things as well.

No I didn't mean that. I meant that war plugin could declare a
depencency set specific to itself in paralell to sets "build" "runtime"
and "test" declared by the core. Later on I noticed that the war
plugin should be using the "runtime" set really.

>>Or along the lines of David's comment
>>
>>
>>
> 
> What if you have more than one class? Sorry, don't understand this one.

It was suposed to mimic css class notation. When there is more than one
you put them all into the attribute, whitespace separated.


>>Or even better along the lines of Michals latest propsal, one of the 
>>aboved with "war" replaceed by "runtime", and the war plugin knowing
>>that it should pick up all artifacts from "runtime" set/production
>>and bundle them together.
> 
> 
> You wouldn't even have to specify this as the WAR plugin could pick up
> the standard runtime jar list production. I see that one as a standard
> one. You could do that in conjunction with an exclude option on the
> depedency. Just so long as the user can control exactly what goes into
> the WAR and what doesn't. Inclusion of a standard production with
> exclusions would probably make more sense with the WAR plugin I think.

I agree.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Reactor processing order is messed up

[Rafal Krzewski]

Scott Stirling wrote:

> I ask, why would it?  It's not analyzing Java source to build a dependency
> graph of the Java packages (a la JDepend or Pasta).  

Sure it does not, there was an idea floating around, of a plugin that
would analyze a source directory and suggest a set of dependencies based
on the contents of the local repository.

> It's sorting a set of
> jar file names. In Maven a dependency is just a jar file name and nothing
> more, right?  Unfortunately, there's no distinction between a static jar
> file/resource dependency and an inter-project dependency where a project
> dependency indicates a need to execute one project (and spit out the named
> jar) before executing the dependent project.

Well, there is no distiction from a single project's point of view.
There is fundamental distinction when you build a cluster of projects
with the reactor -- in such case their interdependencies are taken into
consideration, to bulild them in the correct order.

>>Have you placed the inter project dependencies properly?
> 
> 
> I believe so, but how would I know?  

You don't know what the parts of your project depend on? How do you
manage to build it with Ant or anything else?

> For example, all my projects have a
> dependency on the jar produced by the kernel-system project, except
> kernel-system itself.  Shouldn't kernel be sorted first?  It's not.  It
> comes out second to last in one sort, and fourth in another.

This either means that your POMs are not right, or you are being bitten
by some obscure bug.

> Doesn't anyone use Maven in a waterfall/cascading build, where one project
> builds, outputs a jar, next project picks up that jar, builds, outputs a
> jar, next project uses the jars produced by the previous two projects, etc.
> That sort of thing?

I believe Vincent is building his company's 300+ projects in several
clusters, so he's probably the best source of information on this
subject.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: POM and maven-new

[Rafal Krzewski]

Jason van Zyl wrote:

I believe that  and  can be replaced with a single set of
hints. And here the hints are specifically artifact handler hints.
Maybe I just understand, but for me  (jar,war,tld...) and 
(compile,runtime,test,...) are orthogonal qualities of a dependency.
Type determines the filename, and repository location of the artifact,
but does not affect the kind of processing the artifact will recieve.
Kind (class, nature?) determines in which of the productions you've
mentioned the artifact show up. I don't think that we should mix
those two qualities together, because IMO this will effectively
*decrease* consistency.
Say we have the following POM:


  

  
  
  
jar
true
  


  
  
  
jar
true
  


  
  
  
jar
true
  

  

So instead of an artifact being passed through only one artifact handler
it passes through a chain of artifact handlers and each artifact handler
does what it likes with the artifact based on hinting information.
So we may have some standard artifact handlers in the core, but I see
many of the artifact handlers coming from plugins themselves. When a
plugin is loaded the artifact handlers it provides are loaded into the
artifact handler chain. When it's finished they can be removed. So for
example with the WAR plugin it would have a simple artifact handler that
looked for 'war=true' hint and if found would add that artifact to a
production which was a list of artifacts you wanted packed into a WAR.
All of this is fine, perhaps except the notation. I'd hate to have 
element declared in the POM schema, because it's supposed to be specific
for the war plugin. I'd much rather have:
war

Or along the lines of David's comment



Or even better along the lines of Michals latest propsal, one of the 
aboved with "war" replaceed by "runtime", and the war plugin knowing
that it should pick up all artifacts from "runtime" set/production
and bundle them together.

So I see the POM being able to store an arbitrary map of productions and
it would be up to the artifact handler to name the production. So when
the artifacts are processed any number of productions can be created and
stored in the POM. When a plugin is executed it has access to the POM
and can extract the productions it needs to carry out its task.
So this way everything is offloaded to the plugin. If the standard
productions don't suit the plugin then the plugin provides 1..n artifact
handlers to create the productions it needs. And the artifact handler is
simply triggered by the hinting information.
The  could also be , I don't really care. I'm just
trying to stress that a single set of hints or properties would do the
trick as all we are really trying to do is provide some arbitrary set of
information to a plugin and I believe this will work.
At this moment I don't see any particular use for free-form key=value 
style properties attached to a dependency, but at the same time I cannot
deny that some artifact handler might need that. My preferable syntax 
for those would be


  
value
  

or in case we can't have XML attributes


  

  name
  value

  

We could also use the hinting information to access the artifact type
directory or anything else that would be required in the artifact
processing chain.
See at the top of the message.

I will actually send another message about transitive dependencies to
keep the ideas separated.
Looking forward to it.

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposla] changes in POM needed by new features of maven-new [was:RE: Refining dependencies for test and non-test]

[Rafal Krzewski]

David Zeleznik wrote:

> I start to think of the CSS class or psuedo-class mechanisms. I am 
not sure
why we are not taking advantage of that type of syntax in parsing the POM,
but I could imagine something like:

This seems to me to be the most elegant notation from the propoosed
to date.
The reason why attributes where not used at all in POM was the Betwixt
based parser. I consider this a big disadvantage -- it's kind of like
wearing shoes with shoelaces missing... I know that maven-new is using
xmlpull, but I don't know how will that affect attribute support in
POM. There are some things could certainly used id/ref semantics, for
example  sections.
Now to dependency properties. As others have said, kinds/classes/etc.
provide a perfect substitute for binary properties. The only issue is the
definition of non-binary properties. In XML, I prefer to stay with a syntax
that looks something like:
   theValue

If properties must be defined on a per kind/class basis, then nest the
property element under a kind element:
  
theValueForAllKinds

  theValueForKind1

  
In summary, I would stick to standard XML-style syntax rather than trying to
embed other textual structures inside of XML elements.
Make sense. I hope we'll be able to limit the number of neccessary 
dependedncy annotations, but if we can't get rid of them, this syntax 
seems quite appealing.

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] changes in POM needed by new features of maven-new

[Rafal Krzewski]

Michal Maczka wrote:

I see it differently (as mixture of group and transitive dependencies)

In your main POM you do:


   footolkit.org
   footoolkit
   1.0
   pom  <--- This mean group dependecy
   runtime
   true

This is group dependency with a hint that transitive dependencies should be
followed/resolved.
I see what you mean. I think I just got it upside-down: I was trying to 
specify what deependencies are transitive on the source (export) side,
instaead of the destination (import) side.

Let's say that you do "war:war" for this project. I want to see all runtime
dependencies budled in this case. In addition I don't want to have any extra
metadata 

Simply POM of Footoolkit will be consulted. There we should find (note that
those "strange" "kind"s like war.bundle.true are gone)

   footolkit.org
   footoolkit
  1.0
 
   
 
 footolkit.org
 footoolkit 
 ${pom.version}
 jar
 runtime>

   
 footolkit.org
 footoolkit-tags
 ${pom.version}
 tld
 runtime
   
   
 footolkit.org
 footoolkit-content
 ${pom.version}
 web-content
 runtime

   
 

War plugin will be able to bundle some of types of artifacts ("jars", "tlds"
maybe even "web-content") I don't see a reason to mark them in special way.
I agree. If you dedcide to depend on something, then basicly it's 
runtime dependencies should become your runtime dependencies, shouldn't 
they? In this light, I'm wondering if the the 'transitive' hint is at
neccessary at all!

I don't see any reason why would we need things like: war.bundle.transitive
Why to complicate things? And then you need special markup in other projects
I don't think that you should expect such meta-information there nor you
will be able to control it (some of them won't be yours)
That .transitive thing was a plain silly idea. What I really meant was
 and , but that is irrelevant now.
R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Reactor processing order is messed up

[Rafal Krzewski]

Scott Stirling wrote:

Can anyone shed some light on this?  What I'm looking for is the simple kind of 
declarative depends functionality provided in Ant as , except the dependency is between projects, not targets.  
Ideally I would specify the processing order, not Maven; Maven's not going to 
figure out the package dependency graph of my projects.
Maybe you should not be using reactor at all then. There is  tag 
that allows you to spawn another instance of maven and attain a set of 
goals on a given project.
You could wrap that tag in some Jelly markup to iterate over a list of
projects (,...)

Hope that helps

R.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] changes in POM needed by new features of maven-new

[Rafal Krzewski]

Michal Maczka wrote:
>>As Ben noted, we may need to have dependencies with varying 'transitive'
>>status per kind. For example it is very common that a library is
>>required for compiling and running your project, but at the same time
>>only for running your project dependencies. Suppose we have:

> I don't understand.

A descriptor of a hypotetical web application toolkit, in it's master
project. The toolkit has three sub projects: a jar, a tld and web
contnent drop (js/css).


  footolkit.org
  footoolkit
  1.0

  

footolkit.org
footoolkit-classes
${pom.version}
jar
war.bundle.transitive
compilation.transitive
  
  
footolkit.org
footoolkit-tags
${pom.version}
tld
war.bundle.transitive
  
  
footolkit.org
footoolkit-content
${pom.version}
web-content
war.bundle.transitive
   
  


Then in a war project you declare a dependency on 'footolkit' and get
compile dependency footoolkit-classes, and get the jar, tld and
web-content stuff bundled in your war without any further hassle.

Makes sense now?

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposla] changes in POM needed by new features of maven-new [w as:RE: Refining dependencies for test and non-test]

[Rafal Krzewski]

Michal Maczka wrote:

> 1. I want to support mapping between dependencies in POM and multiple
> classpaths.

First of all, I think this is a great idea.

I would rather called them 'dependency sets' or something because
dependency != jar.

> I see a need of having at least 3 classpaths: compile, test, runtime.
> For the moment I am using 4th classpath: "global" which is used
> in case dependency should be visible in all 3 other classpaths
> and is also useful for backward compatibility.

I'm biased against providing global/all/* set bacause this will make
lazy people put their dependencies where they are not needed.

> I think that the right way of declaring such mapping is by 
> introducing new tag inside : 
> 
> And use it like follows:
> 
> global(default value which is also used when tag was skipped)
> test
> runtime
> compile
> 
> There are few open points there
> (e.g. can we have:  tests, runtime or cactus etc.)

tests
runtime
is probably cleaner to parse.

I think that new sets with arbitrary names should be created on demand:
custom-plugin
should be legal, and then custom-plugin sould be able to do something
like List deps = dependencyResolver.getDependencySet(PLUGIN_NAME);

> 2. I want to prepare a field for <> dependencies. I think that
> is should be controllable if given dependency is transitive or not.
> 
> So I am proposing to use:
> 
> true 
>   or 
> false (default, can be skipped)

As Ben noted, we may need to have dependencies with varying 'transitive'
status per kind. For example it is very common that a library is
required for compiling and running your project, but at the same time
only for running your project dependencies. Suppose we have:

runtime.transitive
compile

getDependencies(String kind) could return both 'kind' and
'kind.transitive' depependencies, and getTransitiveDependencies(String
kind) would return only 'kind.transitive' dependencies.

I'm not sure if this scheme addresses all the needs of dependency
transitioning, and if it's really simplest possible.

> 3. Other proposition is to change a bit a semantic of  tag
> and instead of using:
>  
> 
> 
>true
>true
> 
> 
> 
> To make it:
> 
> 
>war.bundle.jar=true
>ear.bundle.jar=true
> 
> 
> 
> There are at least two arguments for such change:
> a) It is very easy to implement (It's already done in maven-new :) )
> b) It is easier to use for end user (it's shorter)

If we need to have dependencies properties at all, I would support that
change. It's easier to read/write. At the same time I think that
'bundle' issue can be elegantly solved with dependency sets. You would
just declare an a war dependency to be war.bundle and
the war plugin would be able to pick it up.

Not sure about classloader stuff. Should it be handled with dependency
sets, or is that orthogonal to that?

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven j2ee workflow

[Rafal Krzewski]

Scott Stirling wrote:

>>I see this problem from a bit different perspective. Most, if not any
>>single project - multiple jars concerns can be solved by structuring the
>>codebase corectly. 

First of all, please remember that I'm speaking for myself only, not for
the Maven project as a whole. I'm not even a commiter at all. I'm just a
person who uses the, and participates in the mailing lists.

> "Correctly" -- a 30 person project with multiple teams, thousands of lines of 
> code and several 3rd party dependencies doesn't map to the simple "correctness" 
> of, e.g., jakarta-commons-lang.  Ya gotta think bigger, more complicated, and 
> add a few professional managers to understand my situation.

I'm sorry didn't mean to offend you. Be assured that maven works for
things bigger that jakarta commons. Vincent says his company is running
300+ interconnected Maven projects, and the thing I'm working on is
roughly 300k lines of code (cut 30% for javadocs). I know this ain't no
kindergarten, but I couldn't resist saying that...

>>It's not that maven is really lacking anything, it just encourages
>>different approach to codebase management that is currently used by
>>many projects. 

> I would say "enforces" rather than "encourages."  Maven is lacking support for 
> multiple codebases and outputs per project.  Believe me, I would love to 
> organize our whole project like Jakarta Commons, but things are a lot more 
> complicated in medium to large commercial software projects.  But obviously a 
> tool designed to build tip revisions of Jakarta Commons out of CVS is going to 
> have to stretch to accomodate larger and more "sophisticated" (or 'incorrect') 
> project structures.

We are trying to provide you with tools that will enable you do decrease
that complication and make your work easier and more efficient.

>>I'm aware that restructuring may be not a feasible option
>>for many of them, so Maven provides support for 'incorrect' codebase
>>sturcturing to some extent.
> 
> You should reconsider your use of "correct" and "incorrect"; it sort of 
> discounts smart people who are more concerned about whether the tool is 
> reasonably flexible than whether they meet your notion of "correct" project 
> management.

Again it was not my intention to offend you. By 'correnct' I meant
structures that are modular thus easy to manipulate, clear and easy to
understand. By 'incorrect' I meant structures that are unwieldy, hard
to understand, and causing immense suffering whenever  need arises
to add or replace a part of those.

The ambition of the Maven project is to provide guidelines for
structuring the project that are good for the developers - easy to
maintain and understand. The build/documentation tool that is being
developed is just a part of the story. If you structure your project
according to the guidelines, it is expected that you will be able
to decomission Maven tool at some point and replace it with other
tool and the transition process will be straightforward and easy
(this depends much on the tool you are moving to, but Maven guidelines
try to avoid any unnecessary complication on the maven side)

>>Over time this support may be further
>>improved, but this is not a high priority goal.
> 
> It should be.  I think things will get better -- if more people start to use 
> Maven and contribute back to it, everything should improve.  I am willing to 
> help.

That's excellent. Everyone around here is looking forward to your
contributions.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Controlling projects' build order

[Rafal Krzewski]

Scott Stirling wrote:

> How do I control the order in which the projects are built?  Or how do I
> declare my projects in such a way as to make Maven figure them out correctly
> and dynamically?  How does Maven figure out the order?

Reactor creates a graph of projects and does it's best attempt at
building them in the correct order, which means that dependency
projects are build before dependant project. Projects that are not
involved in a dependency relationship are build in arbtrary order
(be it alphabetical ordering of names, or Object.hashCode() ordering
of unmarshalled POMs).

> Maybe I'm doing the wrong thing.  I could define the dependency order in the
> maven.xml as an alternative, but it would seem like I'm missing something
> key about how Maven works if I do that.

You should never need to do that.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Distributing custom goals

[Rafal Krzewski]

Alex Vollmer wrote:
> I have several Maven projects that require a common custom-built Maven
> goal. Can anyone shed some light on how to go about distributing a
> custom Maven goal? Or will each user need to manually install the goal
> into their Maven directory?

You should create a custom plugin containing the goal, deploy it to your
sitewide repository, and then each users should install the plugin from
the repository. I'm not entirely sure if installing plugins from
remote locations really works or is a planned feature, I hope someone
else will give you details on that.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eclipse and Maven - layers overlapping

[Rafal Krzewski]

Dima Berastau wrote:

> 1. generating/updating project.xml from .classpath and .project would
> already be useful.

Not sure about .project, but .classpath file should IMO be generated
from the POM, never the other way around simply because POM has more
information in it. The plugin could watch the POM (and possibly it's
ancestors) for changes and ask the user to update the affected
.classpath files automatically.

> 2. running maven's goals from eclipse runtime

Building atop of Eclipse Ant plugin would be probably the best choice here.

> 3. as would the effort to keep the 2 in sync automatically,

Not sure what you mean here, sorry

> 4. an editor with outline for project.xml/project.properties would also be
> very handy.

I envision it as wizard-like tabbed editor like the one provided for
plugin descriptors by Eclipse PDE.

> I have nothing against JSRs as long as they are useful (= were designed as a
> result of experience based on people using technology) and flexible (= it
> shouldn't take 1 year to change a standard).
> Personally, I think that it would be a lot faster to write a plugin and
> start making use of it (if it turns out to be useful people with a lot of
> free time can standardize it later).

That would also be my preferable choice. :-) Let's make something that
works, then extract the important bits later to make a stnadard, and
finally implement the thing the right way and scrap the prototype.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven j2ee workflow

[Rafal Krzewski]

Dima Berastau wrote:

I think we have a bit of misunderstanding

> Hi,
>  I don't actually tend to think of maven's emphasis on singularity as a bad
> thing.
> Taken in it's pure form producing *multiple* jars (or wars or ears for that
> matter) from a *single* POM seems like a logical inconsistency. Think:
> putting multiple  or  declarations into the POM.

Sorry but I'm unable to make out if you consider that 1-many
relationship right or wrong... Maybe I'm just tired. :-)

>  The point I was trying to drive home is that your single POM should be
> capable of packaging (and hence distributing) your project in different
> ways. ${maven.final.name}.jar ${maven.final.name}.war
> ${maven.final.name}.ear (and ${maven.final.name}-uber.jar for that matter)
> should all be valid project artefacts. 

Amen. These should be valid target artifacts. At the same time, the
general principle is that if a projects generates a war it generates a
*single* war, and it does not generate any other type of artifact at the
same time.

> ejb, war and ear plugins would of
> course have to offer a bit more to be useful. 

Yeah, they are missing deploy/snapshot funcitonality at the moment.

> For example a war file could
> contain a directory of jsps, etc and potentially some classes that would go
> into WEB-INF/classes. I wouldn't want to create a whole new project/POM and
> jar just to stick a utility XML-RPC servlet class which would give XML-RPC
> clients access to my ejbs. 

You are mixing two things here - you are generating a war, but at the
same time you are compiling some java sources into a jar that you want
included into your war. You can solve it "the maven way" (declarative,
that is) by sprouting a jar project from the war project and depending
on it.
You can also solve it "the real world way", (imperative, programmatical)
by creating custom goals in maven.xml that use jar & war plugins to
build your project.

> I don't think any of these ideas are in conflict
> with 'maven philosophy'. It's more a case of bringing maven philosophy and
> the real world closer together.

I hope that at the time we combine Maven's capabilities with modern IDE
capabilities, doing things "the maven way" will be easy and straightforward.

>  By and large what you can do with a jar you should be able to do with
> war,ear and uber-jar (e.g. install/deploy/snapshot/etc).
>  The project's workspace in the repository (remote or local) could then look
> like:
> /jars (could be deliverable and/or dependency)
> /wars (deliverable)
> /ears (deliverable)
> /uberjars (deliverable)
> 
> Some projects are best distributed as wars (web applications), some as ears
> (j2ee applications), some as uberjars (e.g. command line
> applications/background processes) and some as jars (for reuse in other
> projects). Maven should be flexible enough to allow you to manage all of
> those.

That's been agreed on long time ago.

> I actually don't mind the fact that wars and ears cannot be defined as
> dependencies.

I'm not sure about the meaningfullness of ear dependencies, but war
dependencies are definetely going to be supported (to build your ears
declaratively!)

> In fact it seems to me they were not designed to be a dependency format to
> start with (or maybe it's my outdated notion of dependency as something you
> can stick on the classpath).

Yes, the concept of dependenies is beyound that, but in the current
maven, the approximation of dependency=compilation classpath entry works
pretty well. Maven-new is very different in that respect.

> The next logical step (suggested by one of my friends) would be to tie these
> results into the site generation plugin as links under 'downloads' section
> for example.

If they are proper artifacts, they should probably be distributed
through maven repositories, the download sections showing links to the
predefined repository available through http seems to be a good idea
though.
> P.S.
> 
> I absolutely cannot envisage a situation that would make me go back to ant
> :). In fact, I think that maven is capable of a lot more than it does ATM.
> Maven's reactor is a great continuous integration tool for example. 

Reactor is not really intended as a CI tool - Jason has an idea for a
separate Maven based project for that. Too bad he only so little free
time these days... (search list archives for 'Continuum')

> If only
> maven was logging using a framework of some sort (e.g. log4j,
> commons-logging), you could get nightlies with automatic email notification,
> etc in no time.

Email nagging was removed from reactor at some point, but I cannot
recall the rationale. Anyone?

> Correct me if I am wrong, but last time I checked there were
> still quite a few System.out.println() lurking around.

Very probable. They're not the only kind of ugly stuff that hangs on
around there... Patches wellcome :-)

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addition

Re: maven j2ee workflow

[Rafal Krzewski]

Scott Stirling wrote:

>>From what I managed to grasp out of using maven, the golden rule of maven
>>based project development seems to be:
>>IF YOUR PROJECT CAN PRODUCE A JAR (and that's more or less it) IT SHOULD.
> 
> 
> LOL! I would add emphasis on *A*, as in *one*, jar.  The POM assumes single
> codebase components -- which leads to workarounds like two project.xmls at
> the same level, as in (simple 2 codebase scenario):
> secured-codebase-project.xml and non-secured-codebase-project.xml. Try to
> produce two different jars from one component, in which case you'll likely
> have a separate codebase for each jar for a variety of reasons.
> 
> Many software projects are more complex than Jakarta Commons projects, but
> that "Jakarta Commons style" (which are projects typically producing *one*
> jar file) is currently where Maven shines best.

I see this problem from a bit different perspective. Most, if not any
single project - multiple jars concerns can be solved by structuring the
codebase corectly. Two sample scenarios:

1) project that generates API jar and implemenation jar

Move the interfaces that consitutute the API into a package of their
own. Make implementation package depend on the API package. Optionally
create a master project for buiding both of the above using reactor,
plus common POM for extending

2) project that generates server classes and client stubs

All of the codebase resides in the server side project. Client side
project depends on the server side project, and generates the stubs (be
it RMI/JRMP, RMI/IIOP or WSDL with JAXRPC) from binary classes, and
packages them into a client jar

It's not that maven is really lacking anything, it just encourages
different approach to codebase management that is currently used by
many projects. I'm aware that restructuring may be not a feasible option
for many of them, so Maven provides support for 'incorrect' codebase
sturcturing to some extent. Over time this support may be further
improved, but this is not a high priority goal.

R.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven j2ee workflow

[Rafal Krzewski]

Dima Berastau wrote:
I've somewhat modified ejb, war and ear plugin to mimic functionality of the
existing jar plugin including ability to snapshot/install/deploy = the usual
stuff.
If anyone thinks there is some value in this approach I could submit patches
to the relevant plugins. It's not too much work in any case.
Your reasonig seems very coorect to me. Patches bringing j2ee plugins in
line with java plugin WRT deployment are very wellcome!
Other issues you've noticed (like proper multi-level depenencies &
inheritance, and uniform handling of artifacts of different types)
are going to be solved by maven-new, but the changes in j2ee plugins
you are talking about can add a good value to existing Maven right
now.
R.
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )

[Rafal Krzewski]

Brian Ewins wrote:

> The 'official' way to deal with code generators is to chuck their output
> into the 'global list of sources'. Are we suggesting global variables
> are a good thing? Also, this mechanism only deals with .java files -
> there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
> can also be seen as inverting the problem in the previous para - now B
> knows how A works and is pushing its data at A)

Instead of 'global' think about 'valid during a session'. Suppose you
have Maven embedded in an IDE, with your project loaded and all goal
dependency information in place. You click a toolbar icon that invokes
a pre-configured goal on the current project. This starts a new Maven
session for your project. Maven uses the loaded goal dependency
information to build of a graph of goals that need to be attained to
achieve the goal you requested. Then the order in which the goals will
be attained is computed (with the possible outcome of cirular dependency
error message). At this point we have a pipeline formed. The goals that
run at the beginning of the pipeline are usually producers of ... well,
let's call'em 'interim artifacts'. For example, 'java:init' goal would
check for existence of ${basedir}/src/java, and if it's present, would
create a FileSet interim artifact named 'java.source.set' and pass it
down the pipeline. How would that be done? The object would be injected
into the Maven session context. How further elements of the pipeline
know where to look for that interim artifact? The key in the session
context is a part of public API of the plugin that produces it.

I think that most, if not all of the infrastructure needed to implement
that kind of pipelining operation is already present in Maven. All we
need is defining that this is how things should be done, and documenting
the contracts of all plugins -- what 'interim artifacts' they produce
and consume.

> There also seems to be a clash with the Inversion of Control
> principle[1] here: either A is pulling data from B, or B is pushing data
> at A (or equivalently, A pulls from a global, B pushes to a global). It
> should be the framework telling A what files to process, which happens
> to include the output of B because the current 'flow' declares that
> dependency.

I'm no expert at the theory behind frameworks, but what I've described
above seems reasonably well strucured to me. A and B need to agree on
a contract (names of the passed artifacts) and the framework does the
storage/lookup for them.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )

[Rafal Krzewski]

Colin Sampaleanu wrote:
> Jason van Zyl wrote:
> 
>> 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.

Adding this abstraction would allow us to remve specific support for
sourceDirectory, unitTestDirectory, integrationUnitTestDirectory
resources (i.e. jar resources), testResources and
itegrationUnitTestResources in favor of support for abstract 'sources'
(tha you process somehow) and 'resources' (that you copy someplace).
Specific 'somehows' and 'someplaces' are defined by plugins.
I think this would make core smaller & simpler.

>> 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  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.

This made me think... Maybe the  section of the POM is
completly redundant? Maven recommended project layout defines where
the sources of specific type be located. The plugin that processes that
type of sources lets you override the location through
project.properties to make mavenizing existing projects earlier,
and possibly defines a dyna-tag that lets interested parties add
more source paths if they need to. This makes sense for the java plugin,
and possibly other plugins too. Does that sound better, Jason?

> I completely agree with you about having plugins actually be the ones
> doing their stuff with the sources. However, maven has to provide basic
> facilities to plugins for dealing with source directories, and for
> expressing these in the POM (in a section specific to that plugin is
> fine). What feels inherently wrong about the present setup is that the
> POM specifically knows about 4 different source directory types, and
> stops there.  It should really only know about 'source directories', and
> stop there. What is done with the directories is a function of metadata
> (not expressed as xml elements, as presently done) attached to those
> entries, or the fact thay they are in a plugin specific section, and
> various plugins which act on that. Something similar to Michal's
> proposal is actually a lot cleaner than the present setup.

Well, I agree fully with Collin here.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )

[Rafal Krzewski]

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. 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.

I think this kind of change that it's really worth pursuing.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )

[Rafal Krzewski]

michal.maczka wrote:

> won't it be simple just to have:
> 

> 
>java
>src/java
> 
> 
> 
>cactus
>src/cactus
> 
> 
> 
>test
>src/test/java
>
> **/*Test.java
>
>
> **/RepositoryTest.java
> **/JAXPTest.java
>
> 
> 
> 
>aspect
>src/ascpects
> 
> 
> 
>native
 src/cpp
> 


> and then
> 
> 
>   
>  java
>   .
>   
>   
>  test
>   .
>   
> 
>...
> 

I like your proposal very much. I think it's clear, orthogonal, has
natural space for extension (with plugins, of course) and translate to
convenient Jelly (applying JAXP exprs on pom) and Java interfaces.

I give my non-commiter + to the idea.

R.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]