Re: multiproject + javadoc

[Stephen McConnell]

Peter Bright wrote:

Hello.

I have a project that looks like:

root project
 \subprojects
  \subproject a
   subproject b
   subproject c
I'd like to generate a single set of javadoc documents for the entire thing.
One can sort of frig it by setting the root project's sourceDirectory to
something such as "subprojects"; the javadoc goal will then find all the
java files contained therein and build the docs.  But that's not quite what
I want; I want the javadoc generation to abide by the subprojects'
sourceDirectories and also to abide by the subprojects' dependencies (so
that it builds a proper classpath and stops complaining about all the things
it doesn't understand).
Is this doable with the current javadoc plugin?
I'm doing this sort of thing using a some jelly.  Take a look at the 
xjavadoc goal in the following:

http://cvs.apache.org/viewcvs.cgi/avalon/merlin/maven.xml

Cheers, Stephen.


It might be nice to do the same with jxr, too.

***
This message contains information that may be privileged or confidential and is the 
property of Orbian Management Limited. It is intended solely for the named 
addressee(s) and may not be used or disclosed except for the purpose for which it has 
been sent.
Access to this e-mail by anyone else is unauthorised. If you are not the intended 
recipient, you are not authorized to read, print, retain, copy, disseminate, 
distribute, or use this message or any part thereof.
If you have received this message in error, please notify the sender immediately and 
delete the message and any attached documents.
Any opinions, conclusions and other information expressed in this message are those of 
the individual sender and are not given or endorsed by Orbian unless otherwise clearly 
indicated.
Orbian has scanned this e-mail for viruses but accepts no liability or responsibility 
for any onward transmission or use of emails and attachments having left the Orbian 
domain.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--

||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/merlin/distributions/latest|
||
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Dependency issues for junit tests [brain dump]

[Stephen McConnell]

Steve Garcia wrote:

See note at the end 

The "type" and "kind" elements are really doing the same 
function which is really providing attribute information of a sort.

I honestly don't think you would gain more with several 
"kind" elements over several "type" elements. 

What has happened though is the type has come to represent 
part of the path to the artifact but to my mind there really 
wouldn't be much distinction to a first time onlooker between 
"type" and "kind" to me they mean essentially the same thing.


Many who participated in this thread want to specify the following
properties for a dependency:
.jar, .war, .ejb, .class, .zip, .ear and anything else that is a legal
CLASSPATH element in Java.
Whether this is called a "type" or "kind" or "extension" is just a matter of
doing it.  It doesn't really matter.  You're right that  has
manifested itself as part of the artifact file name.  Maybe it isn't needed?
How often are dependency elements differentiated only on type?  Like
commons-lang-1.0.jar and commons-lang-1.0.zip.  I really don't know.  My
example is silly but I don't do much EJB stuff where maybe one would
differentiate artifacts by .ejb or .jar.
To me this is simply a conveinent way of specifying the path entries in the
CLASSPATH.  This says absolutely nothing about how the CLASSPATH is created
(besides the obvious that there is a  element.)

To me if you you look at that block above someone might guess 
the "type" really refers to the packaging and the path in the 
repository.

What we are essentially after is that the handler for a 
particular type deal with the how that type is packaged, how 
it can be found, how it is processed and how it is integrated 
into the build.

With the single "type" element a particular handler should 
know what to do. Might a dependency need more than one type 
of attribute? I honestly don't think so.

With the type = test we are making the assumption that the 
packaging and path refers to a JAR and that it shouldn't be 
part of the standard classpath.


This is the issue - why is that a valid assumption?  A CLASSPATH can contain
any number of valid entries.  It can contain a .zip, .class, .jar, .ear,
even a directory! (well that can't fit in the artifact model).  For a
developer who wants to add the Oracle classes12.zip artifact only to his
unit tests, I don't know how that would look.

  oracle
  classes12
  test

Under your model Maven would try to find the classes12.jar file and that
doesn't exist.  One could also build, for example, test EJB implementations
different than production EJB implementations (for instance that don't have
to do round trips to the server.)  So doing something like 


  company.com
  test-ejb
  test

Again would try to find test-ejb.jar and NOT test-ejb.ejb which is not the
desired effect.

If there is another requirement for a particular artifact for 
testing then you simply make another handler that deals with 
that type.


What's not OK with adding dependecies to  block?

First of all I think that there could be more then two "kind" of 
dependecies. I see at least three kinds: compile-time, runtime, test
There could be an unlimited number of types of dependencies 
as people may decide to arbitrarily handle those in specifiec 
ways with a specific handler but these dependencies but I 
think having them within the unitTest element (at some point 
in the future just  might be more
appropriate) I think it's very clear what they are for.

I honestly don't think "compile-time" and "runtime" are 
things that we will need to differentiate.


For a period of time I felt the same way as you did but there was opposition
at my work about this and they did bring up a legitimate point.  We use
commons.log for our logging package and our commons-log implementor is
log4j.  So log4j is a runtime dependency but not a compile-time dependency.
That is, we want developers only to write Java code with commons.log.  If
they put log4j logging statements in the code we should get a compile error
indicating that the log4j package cannot be resolved.
So it is necessary in this case to specify that an artifact is compile-time
or runtime.  

This actually brings up another point about the discussion of handlers
mentioned.  Log4j is a legitimate compile-time and runtime dependency. There
might be other projects that only want to use log4j.  In that case it's a
compile-time dependency.  So an artifact can play more than one role.  In
that case you have to preserve the attribute information (groupId,
versionId, artifactId so you can find it in the repository) and then use an
additional property to indicate when it is supposed to be added to the
CLASSPATH.
 

Currently most of the time people add runtime requirements or 
testing which the transitive dependency mechanism should handle.

Really, all you want are compile time dependendencies in POM. 
The runtime should be figured out so that during unit testing 
all requirements are gathered.


This sou

Re: Local Repository Location?

[Stephen McConnell]

[EMAIL PROTECTED] wrote:

Hi, could someone tell me where I can locate and set my local repository location?  I have done the setup but it's putting files in a different location.


Try setting the environment variable MAVEN_HOME_LOCAL to the parent of 
the directory in which the repo will be created.

Steve.

Thanks in advance,

-Conrad

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



--
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CORBA IDL

[Stephen McConnell]

Sean Kelly wrote:

I wrote a maven plugin for the OpenORB IDL compiler a while ago.  It 
basically deployed the OpenORB compiler ant task which is where all of 
the actual work was done.


That'd be great. Nothing wrong with OpenORB where I come from.  :)
This content should provide everything you need on the ant taskdef side 
of things.

http://cvs.sourceforge.net/viewcvs.py/openorb/OpenORB/src/compiler/org/openorb/compiler/taskdefs/

Cheers, Steve.


Thanks,
Sean.


--
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CORBA IDL

[Stephen McConnell]

Sean Kelly wrote:
Maven mavens:

I'm exploring Maven for use on a project that has IDL files that go 
through JacORB to become Java source files.  Before I start writing a 
maven-idl-plugin, does anyone else already have such a beast?  I'd 
appreciate taking a look if not outright using what already exists.

I wrote a maven plugin for the OpenORB IDL compiler a while ago.  It 
basically deployed the OpenORB compiler ant task which is where all of 
the actual work was done.

If this sounds relevant I can post some links.

Cheers, Steve.

--
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: custom site.jsl

[Stephen McConnell]

Rajeev Kaul wrote:

I am trying to use a custom site.jsl for my project.  If I try to use the following property to set it for my project:

maven.xdoc.jsl=${basedir}/xdocs/site.jsl

replace the above with

  maven.xdoc.jsl = ./xdocs/site.jsl

Cheers, Steve.

I get the following error during site generation:

BUILD FAILED
File.. file:/E:/maven/maven-1.0-rc2/plugins/maven-xdoc-plugin-1.5-SNAPSHOT/
Element... j:include
Line.. 330
Column 54
null:-1:-1:  Could not parse Jelly script
However, if I replace the site.jsl in the xdoc plugin resources directory, it works fine.



Rajeev Kaul

 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

Re: fop dependencies

[Stephen McConnell]

Emmanuel Venisse wrote:

- Original Message - 
From: "Nicolas De Loof" <[EMAIL PROTECTED]>
To: "Maven Users List" <[EMAIL PROTECTED]>
Sent: Friday, December 19, 2003 1:33 PM
Subject: fop dependencies

 

My project use apache FOP for PDF generation. I need to set POM
   

dependencies.
 

FOP (version 0.20.5) comes with binaries versions of it's dependencies,
   

that I cannot fond on ibiblio :
 

batik 1.5beta4
avalon-framework-cvs-20020806
- Latest batik version on ibiblio is 1.1.1. Batik is now in 1.5, and I
   

think ibiblio should be updated for this.

Now, you can use 1.5 (multiple jars).

 

- I don't know if they're is a "stable" avalon-framework version after
   

06/08/2002

avalon 4.1.4
 

Actually its 4.1.5 - all available on ibiblio under the avalon-framework 
group:

  avalon-framework-api-4.1.5.jar
  avalon-framework-impl-4.1.5.jar
Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

Re: MAVEN_HOME and MAVEN_HOME_LOCAL

[Stephen McConnell]

Glenn, Paul wrote:

Hi,

From what I understand, the location of the user's
repository no longer has anything to do with the
value of MAVEN_HOME (it's where the 'binaries'
are installed).
Yep - makes sense.

The repository is (by default) relative to the
new MAVEN_HOME_LOCAL (${MAVEN_HOME_LOCAL}/repository).
I think this can be overridden with the user's
build.properties (or other overrides), by setting
maven.repo.local to a value.
If MAVEN_HOME_LOCAL isn't set, it defaults
to '${HOME}/.maven'.
So putting it all together, if you don't set
anything, you get ${HOME}/.maven/repository
as the location of the repo.
I think what you really want to do is use
the value of maven.repo.local, rather than
derive it yourself. Is this outside of a plugin?
Yes.  Can't assume the system property - but that's ok - based on what 
your saying and my own digging the following logic should work fine:

   private static String getMavenRoot()
   {
   String local =
 System.getProperty(
   "maven.home.local",
   Env.getEnvVariable( "MAVEN_HOME_LOCAL" ) );
   if( null != local ) return local;
   return System.getProperty( "user.home" ) 
 + File.separator + ".maven";
   }

Thanks for the feedback!

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

Re: MAVEN_HOME and MAVEN_HOME_LOCAL

[Stephen McConnell]

Jason van Zyl wrote:

On Wed, 2003-12-10 at 10:34, Stephen McConnell wrote:
 

Product: Maven 1.0-rc1

MAVEN_HOME = /java/maven
MAVEN_HOME_LOCAL = 
During a build, it seems that Maven will ignore MAVEN_HOME when it copies the 
result to the repository cache. Instead it copies to ${user.home}/.maven
   

First off, what are you trying to do exactly. I don't understand the
sentence above. 

When Nicols' invokes jar:install the resulting artifact is placed by 
maven in the repository under ${user.home}/.maven.  A unit test 
associated with the build is pulling in resources from that repository - 
but the code pulling is the resoruces is assuming that the repository is 
a %MAVEN_HOME%/repository.  What we need to confirm is the logic 
resolution of the user's local repository based only on the availability 
of the MAVEN_HOME and MAVEN_HOME_LOCAL environment variables.

Current assumptions are something like the following;

   private static String getMavenHome()
   {
   String local =
 System.getProperty(
   "maven.home.local",
   Env.getEnvVariable( "MAVEN_HOME_LOCAL" ) );
   if( null != local ) return local;
   String maven =
 System.getProperty(
   "maven.home",
   Env.getEnvVariable( "MAVEN_HOME" ) );
   if( null != maven ) return maven;
   return System.getProperty( "user.home" ) + File.separator + 
".maven";
   }

However, Nocols' case suggests either the above assumptions are 
incorrect or something strage is happening in maven.

Are you talking about a jar:install type operation here?

Yes.

Stephen.

 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

MAVEN_HOME and MAVEN_HOME_LOCAL

[Stephen McConnell]

Product: Maven 1.0-rc1

MAVEN_HOME = /java/maven
MAVEN_HOME_LOCAL = 
During a build, it seems that Maven will ignore MAVEN_HOME when it copies the 
result to the repository cache. Instead it copies to ${user.home}/.maven

Internally in Avalon Merlin, we have a resolution of;

maven.home.local  ->  maven.home   ->  ${user.home}/.maven

which is not behaving in the same manner as Maven's build system.
This is posing a very subtle annoyance for Merlin users who has MAVEN_HOME 
variable set, but not the MAVEN_HOME_LOCAL.

So True / false  for the following statements would be appreciated.

1. You are not allowed to set MAVEN_HOME only. You either set both MAVEN_HOME 
and MAVEN_HOME_LOCAL, or none.

2. Maven's build system has this bug and it has been corrected.

3. Maven's build system has this bug and it will be corrected.

4. "Maven Folks" doesn't understand the problem we are facing.

5. we have misunderstood the resolution if MAVEN_HOME_LOCAL is not set, and 
should fallback straight to ${user.home}/.maven without considering 
MAVEN_HOME.

Cheers
Avalon Development Team
(message forward from Niclas Hedhman)

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

Re: Plugin avalon:meta

[Stephen McConnell]

[EMAIL PROTECTED] wrote:

The avalon:meta plugin fails with the following message:


java.lang.IllegalArgumentException: Malformed tag 'avalon.component'.
Missing required parameter 'name'
 

In the source code that you are processing is a @avalon.component tag.  
The above error suggests that the tag does not include a "name" 
attribute. I.e. it should look something like the following:

 @avalon.component name="whatever"

Cheers, Steve.

When using the ant target provided by avalon, everything works fine..
Any ideas?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

Re: Multiproject javadoc

[Stephen McConnell]

Mikael Lundgren wrote:

Ok, guys...

I realize this was a bit too simple ;-)

But, the thread about Merlin that appeared here earlier today got me 
the answer... so I looked at Merlin in CVS, in particular at the 
maven.xml for the Merlin project and voilá ;-) Now I can build 
aggregated javadocs for my 6 subprojects!

Now, if only I could get a link to this javadoc to magically appear in 
the home page of the top project... that would be something!!! 


You can do this by including a link to the javadoc root in the 
navigation.xml. If you take a look at the Merlin docs you will see the 
complete system APIs referenced at the top level:

http://avalon.apache.org/merlin

The sources for the site docs are in the merlin/platform/xdocs directory.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
||
| Magic by Merlin|
| Production by Avalon   |
||
| http://avalon.apache.org/merlin|
| http://dpml.net/   |
||




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

Re: starting up problems

[Stephen McConnell]

Nicolas Avila wrote:

Hi
   before anything I'm Running Win2k with Service Pack 4
   i'm completelty new in maven, i didn´t know it existed before i tryed to check an IM server, wich runs using merlin, wich is builded by using maven (the im server is also maven builded)
   so i started from the finish on, traced the steps to maven and installed everything (in case of maven i used the installer and .zip files) and it's not working so i camed back to what i thougth was the starting point... i 
   i installed and runned maven with no prob... that seemed to be so
   i removed then all contents and started again step by step
   i used the install-repo file and all seemed to be fine... untill i checked the pathtree and it had installed itself in "c:\maven\bin\%HOME%\.maven\repository" (the first time was it added in c:\Documents and Settings\Administrador\.maven\repository... but i don't know if that happened because of the installer or the zip file [this time i'm using only the zip file])

Nicolas:

You may want to try installing the beta-10 version of Maven. Generally 
speaking this has less problems than RC1.

   i did everything like it's told in the website to be done... maybe there should be a 
couple of missing ""... idk
   i guess that will bring me problems later, so i ask now what should i do
   and... onme more doubt... are ant and JUnit required?... without that maven would 
not run?... i runned it before and that builded merlin without any markable 
problem but i didn't installed none of them
If you have any problems building Merlin you should post the details to 
the [EMAIL PROTECTED] mailing list.  Subscription details are 
included here:

 http://avalon.apache.org/mailing-lists.html

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: Environment variables in project.properties?

[Stephen McConnell]

You can do this is maven.xml.
For example:
 
 
Cheers, Steve.

Daniel Rabe wrote:

I'd really like to be able to use environment variables in my
project.properties. For example, instead of:
cactus.home.tomcat5x = C:/Program Files/Apache Software Foundation/Tomcat
5.0
I'd like to be able to say something like this:

cactus.home.tomcat5x =${TOMCAT_HOME}

I wasn't able to find anything in the maven documentation... is there a way
to do this?
Thanks,
Daniel Rabe
 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: Seriously Customizing the Project Website

[Stephen McConnell]

jiaqi guo wrote:

Hi Stephen,
That's also exactly what I thought.
I used to think about making tornado based on Avalon, but it means too
much development work. 

This would be suprising!  Generally speaking there is leaning curve 
barrier - but once over the barrier developers find that the experience 
very signifance code reduction (I'm talking about 30-40%).  There were 
unnecessary obstacles in Avalon about 18 months ago but these have been 
eliminated - and more recently, with the addition of a formal meta-model 
- well - its drop dead simple - even for composite components like James 
- install/customize/execute!

So I tried to turn on Plexus, but Plexus changes
so fast, it might be the best choice when it's stable enough.
Peronally I prefer Apache solutions. If your interested, Avalon can 
provide you with a bunch of rock solid development and runtime 
facilities that should deliver everything you need.  You should take a 
look at the new web-site http://avalon.apache.org (all maven 
generated).  There are maven plugins for component meta info generation, 
component simulation, and component deployment.  In addition, the latest 
Avalon containers provide support for maven style repositories during 
development and runtime - in fact you can configure applications to use 
different repositories, or even expand reporitories using a block 
installer. Also in the pipeline is intelligent repository management 
including resource access handling on the server that intercepts 
requests for resources relative to a service description (as opposed to 
simple resources requests).

Turbine 3 is not recommended to use, but it already provided many
features and less bugs, it could be easier to make tornado based on it.
Just for reference I'm playing around with Turbine 2.4 (dev content) 
under Avalon Merlin 3.2.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: Seriously Customizing the Project Website

[Stephen McConnell]

jiaqi guo wrote:

My site is another sample of using customized site.jsl.
http://cyclops-group.sourceforge.net
 

I like the stuff your doing with Tornado - have been thinking how to do 
something similar under Avalon with respect to a server side service 
brokerage facility leveraging Turbine.

Stephen.

Regards
Jiaqi Guo
[EMAIL PROTECTED]
http://cyclops-group.sourceforge.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 30, 2003 4:33 PM
To: [EMAIL PROTECTED]
Subject: RE: Seriously Customizing the Project Website

Thanks a million.  That's exactly what I was looking for.

Yoway Buorn
Software Engineer
Imagery Systems Engineering
GENERAL DYNAMICS
Advanced Information Systems
"Make me a fire and I'm warm for a night.  Set me on fire and I'm warm
for
the rest of my life." -- Ancient Didactical Saying


-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 4:32 PM
To: Maven Users List
Subject: Re: Seriously Customizing the Project Website


You can take control of a lot of things by declaring a custom site.jsl.

E.g:

 maven.xdoc.jsl = myAlternativeSite.jsl

The Avalon site used a custom JSL - not much is custom but its custom
all the same.
 http://avalon.apache.org/

Cheers, Steve.



[EMAIL PROTECTED] wrote:

 

I was wondering if anybody has attempted to make any significant
   

cosmetic
 

modifications to the website that is generated by "site:generate"?  I'd
   

like
 

to do things like change the fonts and how the collapsible menus look.
   

I'm
 

even thinking about adding rich content like flash interfaces and
   

applets.
 

And I want to be able to move things around as far as the layout goes.

I'm familiar with the list of xdoc properties but it's apparent that
   

those
 

properties are more geared toward simplification rather than
   

customization.
 

I can modify the plugin itself but as soon as I download a SNAPSHOT.jar
   

all
 

my customizations go away.

So what I'm thinking of is sort of like what "genapp" does.  First, it
   

looks
 

in ~/.maven/template for a customized template, and if not found, then
defaults to the one in the jar.  Is there a directory that
   

"site:generate"
 

looks in for CSS and XSL before going with the defaults?

Yoway Buorn
Software Engineer
Imagery Systems Engineering
GENERAL DYNAMICS
Advanced Information Systems
"Make me a fire and I'm warm for a night.  Set me on fire and I'm warm
   

for
 

the rest of my life." -- Ancient Didactical Saying



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


   

 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: Seriously Customizing the Project Website

[Stephen McConnell]

You can take control of a lot of things by declaring a custom site.jsl.

E.g:

 maven.xdoc.jsl = myAlternativeSite.jsl

The Avalon site used a custom JSL - not much is custom but its custom
all the same.
 http://avalon.apache.org/

Cheers, Steve.



[EMAIL PROTECTED] wrote:

I was wondering if anybody has attempted to make any significant cosmetic
modifications to the website that is generated by "site:generate"?  I'd like
to do things like change the fonts and how the collapsible menus look.  I'm
even thinking about adding rich content like flash interfaces and applets.
And I want to be able to move things around as far as the layout goes.
I'm familiar with the list of xdoc properties but it's apparent that those
properties are more geared toward simplification rather than customization.
I can modify the plugin itself but as soon as I download a SNAPSHOT.jar all
my customizations go away.
So what I'm thinking of is sort of like what "genapp" does.  First, it looks
in ~/.maven/template for a customized template, and if not found, then
defaults to the one in the jar.  Is there a directory that "site:generate"
looks in for CSS and XSL before going with the defaults?
Yoway Buorn
Software Engineer
Imagery Systems Engineering
GENERAL DYNAMICS
Advanced Information Systems
"Make me a fire and I'm warm for a night.  Set me on fire and I'm warm for
the rest of my life." -- Ancient Didactical Saying


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

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: Using jelly script in project.xml

[Stephen McConnell]

James CE Johnson wrote:

The project.xml file isn't executed as a jelly script. It's treated as
an  expression.
   

Drat.

I guess that also explains why I can't set properties/variables in
maven.xml and have them evaluated in project.xml:
maven.xml:

  ...
  
project.xml:

  
 foo
 ${foo.version}
  
 

This (parameterized versions) would be *so* helpful!

Steve.

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

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: sun jars

[Stephen McConnell]

Nathan:

I've been looking into this problem in relation to component deployment 
requirements related to the Avalon Merlin project [1]. Merlin provides 
support for composite components (i.e. coponents that are created 
dynamically based on service provided by other components).  The James 
mail server is such as example - it is a composite component it pulls in 
Avalon Cornersone components as part of its implementation strategy.  
However, in order to deploy James you need the sun activation and mail 
jar files.  Traditionally James has packaged and deployed thair product 
using container specific solutions - however, recent developments over 
in Avalon are providing solutions that are totally linked to the Maven 
repository model.

For example, if you have the Merlin prouduct installed [2], you can do 
the following:

 $ merlin -install http://dpml.net/james/james-server.bar

This command basically populates your local repository with the james 
application including the necessary bundled Sun jar files.  The Merlin 
repository uses the same structure as the Maven repository so you can do 
thing like:

 $merlin -install  -repository %MAVEN_HOME%\repository

We already have a Maven plugin that provides support for component 
deployment based on the content of the Maven repo and it would not be 
too hard to update this to include the install capabilities relative to 
project dependencies.

Stephen.

[1] http://avalon.apache.org/sandbox/merlin
[2] http://dpml.net/merlin/distributions


Nathan Coast wrote:

Hi,

Just wondering if there had been any movement on the licensing of sun 
jars recently?

http://maven.apache.org/sun-licensing-journey.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00641.html
Until such a time as these jars become available via maven (if they 
ever do) what is the best approach to getting round dependencies?  Up 
until now I've been placing some jar that contains dependencies into 
the repo and creating a dependency to it.  E.g. j2ee.jar, 
weblogic.jar.  Whilst this works, it seems a bit ham-fisted, once you 
start sharing the project with other people - unless they're sharing 
the same local repo.

cheers
Nathan


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

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: AW: Executing xdoclet to generate MBeans before compiling

[Stephen McConnell]

Melvin Dave P. Vivas,MCOM/3795 wrote:

Thanks to all who responded.  By the way, do you have some sample
configuration which uses xdoclet?  

Melvin:

When you get this sorted I would love to see an example.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]


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

Re: javadoc w/ reactor

[Stephen McConnell]

Chris:

You can do this by stacking the maven source path before the javadoc 
target is invoked.

 
   
   
   
   
 
 

Cheers, Steve.

Chris Shorrock wrote:

I'm currently using Maven to compile and jar the source for several 
different sub-projects. I'm wondering if there is a way that I can use 
the reactor in a similar way to generate javadocs, but do so, that 
it's one unified document, and not several different javadocs 
documents in each project?

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


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


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