RE: subproject trouble
> So, now the tricky thing. I wanted to source out the
> dependencies-description of the subprojects into another
> xml-files, which are placed in the subfolders nearby the
> project.xml. Probably subproject b and c have the same dependencies...
> Now the problem: When I call maven on the subfolder for the
> subprojects, it works fine. When I call reactor, it will not find
> the external xml, which I included with the usual " ... >" ... "&bla;"-mechanism in the project.xml of the
> subproject. When I give an absolute path for this file, e.g. to a
> web-resource on a webserver, than it works fine. Unfortuately
> not, when I give a relative path (file:blubber.xml). Than the
> reactor overwrites obviously the ${basedir} of the subproject
> with the path of the mainproject. But I don't want to set
> file:subprojecta/blubber.xml.
>
> Is this a bug or did I forget something?
We have been unable to factor out our common definitions into DTDs because
of the exact same reason.Following the principle of least surprise, I would
expect the relative path to the DTD to be evaluated with respect to the
project.xml that actually contains the reference, not the basedir of some
other project. Why don't you file it as a bug on Jira and I will certainly
vote for it. The worst that could happen is that it is evaluated and denied.
I have seen several other threads go by that mention similar problems using
external XML, so I don't think we are alone...
--
David Zeleznik
Principal Architect
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: PomTag fails if project.xml references a DTD
> I have to wonder whether inheritance is really a better way to go over > composition of the project definition. OOP went down the path of > inheritance for a long time, but it is now generally recognised that you > can get yourself into a horrible horrible mess with deep inheritance > hierarchies. Witness component driven design which typically uses > composition to acquire behaviour. I am not suggesting that having > project "fragments" would be a good idea, just that it might be an idea. Needless to say, I completely agree ;-) Although supporting more than 1 level of pom inheritance sounds like a good idea, I am not convinced that it really helps solve some of the more complex use cases. We already use jelly-driven pom composition quite a bit throughout our build framework so that we can share common declarations and definitions and ease our maintainence load. I previously mentioned how our demo projects automatically append the dependencies of their parent library/app project. Each of our projects also has an optional project-tests.xml and project-benches.xml pom. These poms contain additional dependencies and other info needed to specifically run our unit tests and benchmarks, respectively. Admittedly, some of this behavior could now be implemented using user-defined properties that can now be assigned to dependencies. But, adding this info back into the main project.xml and attaching special flag properties means that we would have to override almost all of the standard goals to ignore dependencies that are only relevant for testing and running benchmarks. With our current implementation, it is actually much simpler because we only have to override the test goals so that they parse the additional pom and extract the info needed. We have not really experimented with the OASIS XMLCatalog capability that is now built into Ant. I am not an expert, but it sounds like it might be a "freebie" feature that comes with the xml-commons and only needs to be exposed somehow to the user. Maybe providing support for xmlcatalogs within Maven would be a first step towards defining sharable libraries of XML pom fragments. > Just a thought for the new year. Just my thoughts for the new year as well... :-) -- David Zeleznik Principal Architect ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PomTag fails if project.xml references a DTD
> i have tried your test case because im experimenting similar issues with > entity references (relative paths not resolved in a multiproject > context). if i modify slighty your test case it doesnot fail anymore. > the trick is to pass the absolute path to the maven pom tag. in > your case : > > Thanks Gilles, that does seem to work and I attached your comment to the bug report I filed. However, I am still stymied because in our real workspace the projects are at different levels within the directory hierarchy. In project.xml, the relative reference to the location of the DTD seems always to be evaluated against the basedir of the currently *executing* project, not the location of the project.xml that contains the reference. Therefore if I have: /templates/entities.dtd /projectA /foo/bar/projectB And projectB's pom references the dtd as: Then, I can run maven against projectB fine from its own root directory. However, if projectA uses the m:pom tag to read in projectB's pom, I will get an error because the location of the DTD is now evaluated with respect to projectA's basedir. So for now, XML entities is not a practical solution for us. Maybe the OASIS XMLCatalog facility that now exists in Ant would provide a first-step solution if it were to be incorporated into Maven. ------ David Zeleznik Principal Architect ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PomTag fails if project.xml references a DTD
Hi Jason,
> Just out of curiosity how many levels of inheritance do you use?
We currently have 3 levels in our hierarchy => 2 levels of inheritance. In
addition, we have the cross-cutting aspects of trying to factor out and
share common definitions, such as developer info and 3rd party library
dependency definitions. I will try to describe a little bit about our build
architecture, keeping in mind that we started with beta7 so we may be still
using legacy techniques due to sheer inertia.
At the top level, we have "template" projects, one for each project type.
Our broad categories here are libraries, demos/samples, desktop apps,
web-apps, and deliverable products. The differences are not so much the
template project.xml's but the maven.xml's that define unique pre/postgoals
for each template type. All of the templates share some common properties by
using jelly:util to explicitly read in a shared properties file. Each of our
maven projects then extends the appropriate template project. The final
level is our demo/example projects which are mini-apps nested within the
directory structure of the relevant library or application project.
Typically, we have a large number of these (20+) demos for each higher
level project. Each demo has a logical dependency on the library project it
belongs to, and therefore to the library's dependencies as well. However,
demo projects extend the demo template and do not explicitly reference the
library project to which they belong. Therefore, to make maintainence of our
demos (which are by far the most numerous) easier, the template maven.xml
for demo projects has a bunch of jelly that reads the parent library's pom
and adds its dependencies to its own and also appends the classpath.
> You
> probably don't watch the commits but in the maven-project component I
> have arbitrary levels of inheritance working. This component will be
> used be integrated in Maven soon.
Is this related to the transitive inheritance capabilities that have been
mentioned on this list before? Is this something planned for v1.0 or after?
To be quite honest, I am not sure that direct pom inheritance would really
be applicable in our case. Our demo projects are quite different in
structure, properties, goals, etc. from the library they pertain to.
Therefore, a demo project does not pass the classic "is a" test for
inheritance. We just want to be able to auto-magically add the library
project's dependencies and classpath to the demo project. The maven:pom tag
works fine for us and allows us to selectively decide which attributes of
the Project we want to merge.
Our use of XML entity definitions was our recent attempt to solve a
cross-cutting refactorization of developer info, etc. We have approx 250
individual maven projects and growing fast. When a developer's id or email
address changes, we want to be able to change it easily across all projects
she is involved in. Similarly, all of our projects need to be built against
identical versions of third party libraries. For example, we really need to
have a shared common dependency definition for JAXP or Servlet apis that all
projects can reference. When we decide to migrate our products to a new
version, we would like to be able to change the definition in one place.
Admittedly, we can do this with properties:
${davidzeleznik.name}
${davidzeleznik.id}
${davidzeleznik.email}
${davidzeleznik.org}
${davidzeleznik.tz}
Developer
But, it is alot easier to be able to define a complete XML entity:
David Zeleznik
zeleznik
[EMAIL PROTECTED]
ILOG
-5
">
&DavidZeleznik;
Developer
Writing this response has got me thinking that both problems, selectively
sharing attributes between demo and parent projects and shared lib/developer
definitions, could be solved by some type of database of XML fragments that
could be included into the poms. I am not sure if the OASIS XMLCatalog
facility provides this kind of capability. Unfortunately, I am not a real
XML guru. However, whatever the implementation, I am thinking that it is
something that could be layered on top of Maven as we know it today, not
built into the Maven core. Anyway, just brainstorming here...
> > To further refactor
> > our project definitions, we tried to use XML entities in some
> common DTD's
> > to define such things as developer info, etc. However, it seems
> that in rc1
> > the PomTag fails to parse a project.xml that references a DTD.
> If it worked prior to rc1 and now it doesn't then I think that would
> count as a bug.
I have no idea if this worked prior to rc1. We tried to add DTD references
as an experiment during the last few days and we have been using rc1 already
now for 2 months or so. I have filed M
PomTag fails if project.xml references a DTD
Hi, I am about to submit a bug report on Jira, but I wanted to post details to the list first. We make extensive use of the PomTag (ie. m:pom) in our jelly scripts and plugins to be able to share dependencies and other project properties beyond the single inheritance of . To further refactor our project definitions, we tried to use XML entities in some common DTD's to define such things as developer info, etc. However, it seems that in rc1 the PomTag fails to parse a project.xml that references a DTD. I have attached an extremely simple test case. Just unzip and try "maven clean". The error I get is: [echo] Reading other project... File.. file:/.. ./PomTagDTDTest/ Element... m:pom Line.. 8 Column 63 error getting project BUILD SUCCESSFUL Total time: 6 seconds If I comment out the DOCTYPE/DTD reference in otherProject.xml, everything proceeds fine. I am wondering if this should be considered a bug (it certainly seems to be one to me)? -- David Zeleznik Principal Architect ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- PomTagDTD.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Source code analyzer for unused method detection?
This is a standard feature of most code obfuscators that operate at the bytecode level, not on the source code. In particular, we use DashO to do exactly this (in addition to other munging). However, as others have stated, in the face of instrospection, reflection, dynamic proxies, etc. you cannot expect a completely automated solution. Determining an accurate list of unused non-public methods in a large software system is not something to tackle casually and will require a serious investment in developer effort. In addition, any future changes to the code will require a fresh analysis effort. -- David Zeleznik Principal Architect ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- > -Original Message- > From: Tim Anderson [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 05, 2003 1:48 AM > To: Maven Users List > Subject: Source code analyzer for unused method detection? > > > Hi, > does anyone know of a code analyzer which can detect unused methods? > The PMD plugin only reports on unused private methods - I'm > looking for one > which can also do public or protected methods. > > Thanks, > > Tim > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jbuilder goal?
Sounds like you are using beta10 and encountered MAVEN-593: http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-593 Fixed in RC1 (along with several other jbuilder plugin issues) -- David Zeleznik Principal Architect ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- > -Original Message- > From: Elias Sinderson [mailto:[EMAIL PROTECTED] > Sent: Monday, September 29, 2003 7:52 PM > To: Maven Users List > Subject: jbuilder goal? > > > Hey now, > > After using Maven for a week or so, I discovered the 'jbuilder' goal (!) > but executing 'maven jbuilder' generated an error stating that "A > JBuilder installation could not be found." Referring to the online > jbuilder plugin information, I attempted setting various properties > manually on the command line but only got the same error. Examining the > plugin.jelly script in > ~/.maven/plugins/maven-jbuilder-plugin-1.3-SNAPSHOT, it appears that the > value of jbDefaultProject is somehow null at runtime... > > I do not see anywhere in the plugin.jelly script where this value is > set, so how can I get it to be something other than null? I attempted to > set it on the command line using -D, but this led to a > NullPointerException somewhere in jbuilder:generateProjectLibrary... > :-( Any assistance would be appreciated, as right now I'm not even > sure that anyone has gotten 'maven jbuilder' to work. > > > Regards, > Elias > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Resolving Snapshot Dependencies, SnapshotResolver, and DependencyVerifier
Currently, the release plugin resolves snapshot dependencies by using the XXX-snapshot-version file in the remote repo. This is fine as far as it goes, but has 2 severe limitations for us: 1) SnapshotResolver is hardcoded to only check ibiblio, the remote repositories specified in our build properties are totally ignored. Is this a known issue? I can find nothing in JIRA on this 2) In this scenario, the developer is working on artifact A which normally depends on a snapshot of artifact B. He/she has some heavy duty debugging to do on A and wants to temporarilly stabilize on a fixed version of artifact B. At the same time, others are actively working on B and deploying new snapshots. Ideally, the snapshot-version file should be downloaded to the local repo alongside the snapshot jar. In this way, the user always knows exactly what version timestamp they are using. It also allows them to easily convert their local snapshot dependency into a timestamped version. This avoids the issue of another developer updating B's snapshot in the remote repo behind their back. Item 2 is really important for us so that each developer can know exactly each dependency version they are using when they use snapshots. The only way I see to implement this is to hack the DependencyVerifier. I can think of some other scenarios where it would be useful to plugin customized verifiers. Is there any thought to making this possible via a factory? Currently, Project.initialize() is hardcoded to instantiate and set the DependencyVerifier instance on itself. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JBuilder plugin major updates
FYI, I have updated the JBuilder plugin patches attached to MAVEN-461. The main change is from a user's suggestion. Now, library files that are automatically generated from versioned (not snapshot) artifact dependencies are versioned themselves. This is also true for snapshot dependencies where an unversioned library file has not been created yet from the corresponding artifact. As before, if an unversioned library file has already been created for a snapshot dependency, the unversioned library will be referenced. Two other small changes are that I added support for JBuilder 9 and I added a maven.jbuilder.verbose property to help when debugging. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Refining dependencies for test and non-test
Hi Paulo, > Michal seems to be currently working in some tags for > the dependecies, where you can say what of dependecy > you have. > > This way you can say to maven that servlet.jar is a compile > dependecy, and not a runtime one, so it will not be copied > to a war, for example. And you can define your own s. > > This way you will be able to handle your tests classpath. Thanks for the info, that sounds like it would help us out greatly. We are still using beta8 because we ran into so many bugs with beta9. Do you know if this new capability is in the current CVS head? If so, where would I look for a a good example of its usage? Thanks, -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - 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]
Hi Michal, I don't have a lot to add to the comments that others have already made. But, here goes... When parsing XML, I prefer to see separate elements rather than comma-separated or multi-line text within a single element. Despite the verbosity increase, I therefore prefer: kind1 kind2 or over kind1,kind2 This also means that I don't care for property-style definitions declared as the inline text of an XML element as you propose. But, I think that the issue needs to be rethought as others have already suggested. Also, I personally don't like the name "kind", it is very generic and conveys no meaning. If we think of a dependency belonging to 1-n sets, then 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: 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. ------ David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Refining dependencies for test and non-test
Hi, AFAIK, the issue of separate paths for building and testing has not been addressed in Maven. We have a situation that sounds similar to yours. We have several test frameworks and we use 0..n of these frameworks in any given project. However, we do not want these test frameworks to be put in the compile class path for the regular project source code- we only want the test frameworks in the compile and run path for the unit tests. Each test-framework is its own project and is deployed to our central repository. What we have done is to standardize on an optional project-tests.xml descriptor that specifies the unit test dependencies for a project. We then have pre and post test goals that read the dependencies from this optional pom and add them to the test classpath by calling these 2 goals: I hope this gives you some ideas. Right now, mucking with Maven's dependency classpath is quite messy. It would be nice if there was a set of easy-to-use tags so that a plugin could do and undo changes to the classpath, like a stack. However, this solution works fine for us now. Regards, -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- > -Original Message- > From: Scott Stirling [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 04, 2003 8:07 PM > To: 'Maven Users List' > Subject: Refining dependencies for test and non-test > > > Hi, > > Wondering how and whether it's possible to refine a project's > dependency set > so that unit/integration test dependencies are separate from non-test > dependencies. > > For example, if I have jars that a JUnit extension library needs > at runtime, > but which I don't want to have in the classpath at build time for > my classes > (or perhaps my classes require a different version of a jar), how do I > separate them at compile time and/or runtime? > > Thank you, > > Scott Stirling > Framingham, MA > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JBuilder plugin major updates
> Woopsno patchcan you try adding it to Jira?? Okay, I have opened MAVEN-461 and attached the latest version of my plugin. One glitch is that I committed the report with some typos in the description section and I do not see how to reedit the report. I guess it is a small issue in the larger context... -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JBuilder plugin major updates
Here's my latest update to the JBuilder plugin. It now adds resources to the JBuilder project source path. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem finding maven-j2ee-plugin-1.1.jar
> I am progressing with building maven from cvs, however I have hit a > small problem. Maven is looking for: > maven-j2ee-plugin-1.1.jar > > in the boot stratp, but there only seems to be snapshots available at: > http://www.ibiblio.org/maven/maven/jars/ FWIW, I reported this problem 2 days ago and noone has responded yet :-( It is the maven-j2ee-plugin dependency listed in the project.xml for the struts plugin. I changed the reference from version "1.1" to "1.1-SNAPSHOT" and everything was fine for me. ------ David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Building struts plugin fails for maven-j2ee-plugin-1.1.jar dependency
The struts plugin defines a dependency on version 1.1 of this maven-j2ee-plugin. However, this version does not exist on ibiblio. I changed this to specify version 1.1-SNAPSHOT and my build of the plugins now completes fine. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant disappearing from default namespace?
Hi, On my latest CVS update, I notice that most of the plugins are now explicitly specifying the ant namespace to invoke Ant tasks. From the latest java plugin.jelly: Does this mean that Ant will no longer be part of the default namespace??? If so, I strongly disagree with this move. It will severely impact compatibility for those of us that have already invested man-months of effort in developing build systems based on Maven. In addition, it really hurts one of the main selling points I have been making to other teams within my company, that their large investment in Ant code can be migrated to Maven as-is. It is critical that you keep us informed on your plans in this area. Thanks, -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: integration tests
FYI, there was some discussion on this issue a while back. But currently,
the integrationUnitTest elements of the pom are not being used anywhere. We
wrote this little hack that seems to be working well for us:
Running ${maven.test.mode} tests
${context.getVariable(includeProp)}
${context.getVariable(excludeProp)}
This allows us to use the unitTest element of the pom to define the
inclusive fileset of all tests that can be run against the project. We then
allow to run named test subsets by setting the maven.test.mode property. For
example, if you set maven.test.mode=quickanddirty, then you can have
additional includes and excludes defined in your project properties:
test.quickanddirty.excludes = **/lengthytests/**, ...
test.quickanddirty.includes = **/only-the-quick-tests/**
We then attach filterTests as a preGoal of test:test. Right now, we are only
supporting the default "all" and the optional "smoke" test modes. But the
mechanism is extensible to support any number of named test modes. Hope this
helps you out.
------
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
> -Original Message-
> From: Stephen Haberman [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 02, 2003 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: integration tests
>
>
> Hi,
>
> I'm working on a webapp where I've got a bunch of domain model unit
> tests in src/test and then want to put some HttpUnit integration
> tests in something like src/iu-test or src/web-test.
>
> I was hoping to use the pom's integrationUnitTestDirectory element,
> but it seems to be no longer used? Does anyone have a best practice
> way of going about having two different sets of JUnit tests?
>
> After giving up on finding a nice, built-in way, I copied some of
> the Jelly code out of test's plugin.jelly and tried to do this in my
> own goal in maven.xml:
>
>name="junit"
> classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask">
>
>
>
>
>
>
>...snip... />
>
> But the taskdef fails with a NoClassDefFoundError for
> junit.framework.TestListener, even though the
> pom.getDependencyPath('junit') line should import junit just as it
> does (and works) for a javac task prior to this taskdef.
>
> My naive thinking is that this is some classloader issue that is
> being/will be worked out, but I've tried it with beta-8 and HEAD to
> no avail and can't think of a work around other than manually
> calling JUnit via the java task. But ideally I'd like to avoid it.
>
> Is there an easier way to do this that I'm not just seeing?
>
> Thanks,
> Stephen
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bootstrap build info
> Maybe you have no ant-optional-x.y.jar in that repo??? Or a bad > onetry > blowing it away. Thanks so much! Indeed, the ant-optional-1.5.1.jar in my repo was corrupted and only 224K (should be 640K). Not sure how that happened and why I never noticed it during a month of daily maven usage. Doesn't matter, my bootstrap builds are fine now. Regards, ------ David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bootstrap build info
i.App.main(App.java:1080) [exec] ... 6 more The only thing I can guess is that some dependency cached by beta8 in my local repo is somehow satisfying a beta9 dependency, but is incompatible with it. Note, that when I do a bootstrap build against my beta8 local repo, I do not see any new downloads from ibiblio. I hope this helps pinpoint the issue for you. Regards, -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bootstrap build info
> > After using beta8 for several weeks, I tried unsuccessfully
> several times to
> > build Maven from source. In the end, I discovered that if you have a
> > ${user.home}/build.properties file, this must be deleted or temporarilly
> > renamed before starting the bootstrap build.
>
> No, it does not. I have a ~/build.properties file and I bootstrap all
> the time.
Are you defining maven.repo.local to point to a directory other than
$MAVEN_HOME/repository? This seemed to be the problem for me.
------
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
> > This crucial bit of info is
> > missing from the docs at
> http://maven.apache.org/start/bootstrap.html. In my
> > case, I had an overridden maven.repo.local property pointing to my beta8
> > repo cache. This seemed to be the culprit that was causing the bootstrap
> > builds to fail. In the end, it seems safest just to make sure
> that you do
> > not have any $user.home/build.properties file before starting the build.
> > Maybe someone can update the docs?
> >
> > --
> > David Zeleznik
> > ILOG - Changing the rules of business
> > mailto:[EMAIL PROTECTED]
> > http://www.ilog.com
> > --
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Defining goals in imported scripts
Hi Yet Again, This may be more of a Jelly question than Maven, I am not sure. We have a large maven.xml that is associated with our template project.xml. We have been adding many common goals, etc. to this template maven.xml and it has gotten larger and larger. We are now trying to break maven.xml up into smaller scripts that are imported by maven.xml. This is where we are encountering some type of goal scoping behavior that we do not completely understand. For example... doit.jelly looks like this: You asked me to do it! Now, if my maven.xml directly imports doit.jelly: The doit goal is not defined and I cannot execute "maven doit". However, if I import the nested script within the context of a goal I can attain goals in the nested script. Here is the revised maven.xml: Now, I can successfully execute "maven reallyDoit" and the doit goal is attained. Can someone explain this to me, is this expected behavior? Thanks, ------ David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven property processing and startup sequence
Hi,
The sequence that Maven processes its properties files is documented at
http://maven.apache.org/reference/user-guide.html#Properties%20Processing.
However, this page does not document how property file processing relates to
pom and maven.xml processing and the rest of Maven's startup sequence. I
first needed this info when I was trying to determine why setting
maven.repo.remote from my maven.xml was ineffective for dependency
resolution. I did a bit of experimenting, and here is the Maven startup and
initialization sequence I have found:
* ${maven.home}/bin/driver.properties is processed
* ${project.home}/project.properties is processed
* ${project.home}/build.properties is processed
* ${user.home}/build.properties is processed
* project dependencies are resolved
* maven.xml for the parent project, if any, is compiled, any inline jelly
script is executed
* maven.xml for the project is executed, any inline jelly script is
excecuted.
* Plug-in default properties are processed for those that are not already
defined
* Any inline plugin.jelly for all plugins is executed
* goals are executed
Can anyone comment on this for accuracy? I would like to make sure that I
have a complete and proper understanding of Maven's initialization sequence.
Thanks!
------
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bootstrap build info
Hi,
After using beta8 for several weeks, I tried unsuccessfully several times to
build Maven from source. In the end, I discovered that if you have a
${user.home}/build.properties file, this must be deleted or temporarilly
renamed before starting the bootstrap build. This crucial bit of info is
missing from the docs at http://maven.apache.org/start/bootstrap.html. In my
case, I had an overridden maven.repo.local property pointing to my beta8
repo cache. This seemed to be the culprit that was causing the bootstrap
builds to fail. In the end, it seems safest just to make sure that you do
not have any $user.home/build.properties file before starting the build.
Maybe someone can update the docs?
--
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: inter-project dependencies for the Eclipse plugin
This is interesting for me also because I am trying to tackle a similar issue for improving how the JBuilder plugin generates JB project files. In JB, a project can reference dependent "libraries". A library is a configuration file that can reference classes, jars and optionally source files. A library can also declare dependencies on other libraries. JBuilder then builds its project classpath from the entire tree of all referenced libraries. Any library that defines java source files will be included in JBuilders symbol completion, etc. Library definitions are stored in the user's home directory where they can be shared among projects. So, my first take at solving this is to generate the JB project file and iterate over each of the project's dependencies. I then convert each dependency into a reference to a JB library definition of the same name. If the library has not been defined yet, I create a basic library definition that just references the jar in the local repo. From the pom dependency there is no way for me to determine whether the source code for the dependency/library exists on the local workstation and there is no way to determine if the library has dependencies of its own. After creating the JB project file, I then create a library definition file for the maven project that can be referenced by other projects. This library definition will overwrite any basic/jar-only library definition and contains all of the source and dependency info. Therefore, I am hoping that the user will be able to go to each maven project on their workstation, run the JBuilder plugin, and result in a full set of JB project and library definitions. Libraries that they are not building locally will just reference the jar in the local repo. Libraries that they are building locally will contain full source and dependency info. Now, my second idea is to somehow take advantage of the ability to deploy pom's to the remote repo. I do not see any place these are used in the Maven code, but I think it is an avenue to obtain full info on a dependency. Ideally, it would be cool to somehow convert a Dependency object into a full Project object by downloading the dependency's pom from the repo. Then there could be a mechanism for traversing the entire tree of Projects, rather than the current 2-level Project/parent - Dependency/child structure. ------ David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- > -Original Message- > From: Mark H. Wilkinson [mailto:[EMAIL PROTECTED] > Sent: Friday, March 28, 2003 2:37 PM > To: Maven Users List > Subject: Re: inter-project dependencies for the Eclipse plugin > > > On Fri, 2003-03-28 at 19:12, Jeffrey D. Brekke wrote: > > This is very interesting. We have 36 projects, all with > > interdependencies ( some build, some test, some runtime ) and to have > > the reactor/maven maintain the eclipse projects like this would be > > cool. Is there a dep heirarchy in eclipse where like a project dep is > > used if present before a jar dep? Then we could just put both deps in > > the project. > > In Eclipse if you have a number of separate projects open in your > workspace you can specify dependencies between them, so you can say that > project 'foo' depends on project 'bar' in the same workspace. This > results in bar being on the classpath when foo is compiled. It also > helps to tie together the internal model that Eclipse uses - you can > click on a symbol in the foo project and it'll take you to the source in > the bar project or show you the javadoc for example. If you were > depending on a jar file you'd have to associate a source directory with > the jar file to get this to work. > > What I tend to do is break a system down into modules, each of which is > a separate project with (typically) one source tree in each project. I > would then use Eclipse's classpath editor to specify for each project > which other projects were required. > > At the moment there doesn't seem to be a way to model this kind of > dependency in the maven project model - dependencies are more-or-less > assumed to be versioned jar files. I think it would be useful to have a > way to model this kind of dependency hierarchy, if only so project files > for IDEs work more cleanly. > > I don't know whether this kind of dependency information would be of use > when building multiple projects under reactor - presumably that can work > with jar file dependencies? > > -Mark. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overriding standard plugin goals in maven.xml
> Did you file this as a bug report? I just filed it as Maven-356. I was unsure if such goal overriding was supported or not- it was something we just happened onto as we migrated to Maven and it seemed to work well for us (until now). Thanks for confirming that this is supposed to work, -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- > "David Zeleznik" <[EMAIL PROTECTED]> wrote on 28/03/2003 01:13:33 PM: > > > Hi All, > > > > We have a need to override several standard plugin goals for our project > > builds. In these cases, providing a pre or post-goal is not enough. For > > several weeks, we have been successfully overriding these built-in > plugin > > goals in our maven.xml scripts. Now, we have discovered that whether our > > version of the goal or the plugin version executes depends somehow on > the > > execution context- we cannot obtain consistent override behavior. Here > is a > > very simple example of a maven.xml: > > > > > > > >The java:compile goal in maven.xml > > > > > > > > And here is the behavior we see: > > > > maven java:compile - our overridden goal in maven.xml executes > > maven java:jar - the java:compile goal in the plugin executes > > maven clean java:compile - the java:compile goal in the plugin > executes > > > > So, is there anyway to provide a consistent override/replacement for a > goal > > that has been defined by a plugin? This is really critical for us. We > are > > currently using b8 and I hope someone can point me in the right > direction on > > this. Thanks! > > > > -- > > David Zeleznik > > ILOG - Changing the rules of business > > mailto:[EMAIL PROTECTED] > > http://www.ilog.com > > -- > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: absolute Paths and relative paths
> I'm currently working on a plugin which produces documentation for
> a cocoon based project. However I've hit a little trouble with file
> names.
>
> I want to perform an xsl transform on all appropriate files in the
> source directory, (*.xsl for the xslDocumenter, *.xmap for the
> xmapDocumenter etc.) However I also want to pass them their filenames
> and the relative path from the source directory.
>
> My question is how do get that relative path?
Take a look at the jar:deploy goals in the java plugin jelly. There are some
examples of creating relative paths from an absolute path and a root
directory. Hope that helps you out,
--
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
>
>
>
>
> excludes="**/*.xsp, **/*.xml"/>
>
>
>
>
>
> in="${xmapFile}"
> out="${xmapFile}.html"
> >
> <param name="filename" expression="${xmapFile.name}"/>
>
> <!-- it is here that I want to get the path from the source directory
> -->
> <param name="site"
>expression="${xmapFile.absolutePath}"/>
>
>
>
> Any help would be appreciated as I'm really quite stuck.
>
> (Is the xmapFile above something like a java.io.File?)
>
> Thanks,
>
> andy
>
> --
> [EMAIL PROTECTED] / [EMAIL PROTECTED]
> SDF-EU Public Access UNIX System - http://sdf-eu.org
> "Tsk. The arrogance of Truth"
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Overriding standard plugin goals in maven.xml
Hi All, We have a need to override several standard plugin goals for our project builds. In these cases, providing a pre or post-goal is not enough. For several weeks, we have been successfully overriding these built-in plugin goals in our maven.xml scripts. Now, we have discovered that whether our version of the goal or the plugin version executes depends somehow on the execution context- we cannot obtain consistent override behavior. Here is a very simple example of a maven.xml: The java:compile goal in maven.xml And here is the behavior we see: maven java:compile- our overridden goal in maven.xml executes maven java:jar- the java:compile goal in the plugin executes maven clean java:compile - the java:compile goal in the plugin executes So, is there anyway to provide a consistent override/replacement for a goal that has been defined by a plugin? This is really critical for us. We are currently using b8 and I hope someone can point me in the right direction on this. Thanks! -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JBuilder Plugin
> Cool,
>
> I'm the original developer of this plugin. It's just a simple version of
> jbuilder project generation.
>
> If you want to complete/correct this plugin, I appreciate it.
> If you send a patch, I'll apply it.
Thanks. Do you have any comments on the strategy I proposed for creating and
"installing" library files? My thinking was to keep things simple and
generated JBuilder project and library files would be strictly local to an
individual's workstation. I do not see much point in trying to make them
deployable artifacts. With the workstation-specific path issues involved, I
am not sure that this is even possible or desirable.
> P.S.:.jbuilder* directory isn't necessary in ${user.home}, I propose you
> put this value in a plugin property.
Thanks for the tip. We have a variety of JBuilder versions scattered around
our team and I tried to make a best guess algorithm for locating the user's
default Project file. In fact as we use the plugin more, we may decide that
some of the properties I currently take from the default project should
instead be specified as Maven properties. Some are truly user preference
defaults, but others should be standardized for a particular project.
--
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
------
> -Message d'origine-
> De: "David Zeleznik" <[EMAIL PROTECTED]>
> A: "Turbine Maven Users List" <[EMAIL PROTECTED]>
> Date: 26/03/03
> Objet: JBuilder Plugin
>
> Hi,
>
> We are a heavy user of both JBuilder and IDEA and have found that the
> current JBuilder plugin is much less functional than the IDEA plugin for
> generating project files. I have started working on improving the
> jbuilder:generate-project goal, but would like to know if anyone else is
> working in this area. I will be happy to send my changes to the list if
> anyone is interested. I just do not want to conflict if there is active
> development on this plugin.
>
> As to the jbuilder:generate-library goal, this one seems completely
> broken
> and actually generates circular references. I am not sure what the
> original
> developer had in mind. My idea is to generate library files directly
> into
> the user's jbuilder home directory where they can then be referenced by
> the
> generated JBuilder projects and other libraries. If a person does
> generate-project and some of the projects dependencies do not have
> library
> files created yet, a default library definition will be created that
> simply
> references the jar in the local repo. The user can then override this
> default library definition by going to the dependency project and doing
> generate-library. This will generate a library definition that includes
> the
> source code. I am also planning to generate versioned library
> definitions,
> rather than just using the artifactId like the current plugin does.
>
> I have attached my first rough draft of my generate-project
> improvements.
> Note, that handling of the project dependencies and libraries is not
> implemented yet. It is next on my todo list.
>
>name="jbuilder:generate-project"
> description="Generate JBuilder [id_project].jpx file">
>
>
>
>
> Creating ${basedir}/${pom.artifactId}.jpx ...
>
>
>
>
>
>
>
>
>
> value="${pom.getPluginContext('maven-javadoc-plugin').getVariable('maven
> .jav
> adoc.destdir')}" />
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> value=".jbuilder8,.jbuilder7,.jbuilder6,.jbuilder5,.jbuilder4,.jbuilder"
> />
> delim=",">${jbuilderDirs}
>
>
>
>
>
>
>
>
>
>
> +-
> - cho>
> | WARNING!
> |
> | A JBuilder installation could not be found. The project
> files
> | being created will contain default values.
>
> +-
> - cho>
>
>
> Reading default project ${jbDefaultProject}
>
>value="${defaultProps.getProperty('sys[0].AuthorLabel')}" />
>value="${defaultProps.getProperty(&#
JBuilder Plugin
Hi,
We are a heavy user of both JBuilder and IDEA and have found that the
current JBuilder plugin is much less functional than the IDEA plugin for
generating project files. I have started working on improving the
jbuilder:generate-project goal, but would like to know if anyone else is
working in this area. I will be happy to send my changes to the list if
anyone is interested. I just do not want to conflict if there is active
development on this plugin.
As to the jbuilder:generate-library goal, this one seems completely broken
and actually generates circular references. I am not sure what the original
developer had in mind. My idea is to generate library files directly into
the user's jbuilder home directory where they can then be referenced by the
generated JBuilder projects and other libraries. If a person does
generate-project and some of the projects dependencies do not have library
files created yet, a default library definition will be created that simply
references the jar in the local repo. The user can then override this
default library definition by going to the dependency project and doing
generate-library. This will generate a library definition that includes the
source code. I am also planning to generate versioned library definitions,
rather than just using the artifactId like the current plugin does.
I have attached my first rough draft of my generate-project improvements.
Note, that handling of the project dependencies and libraries is not
implemented yet. It is next on my todo list.
Creating ${basedir}/${pom.artifactId}.jpx ...
${jbuilderDirs}
+--
| WARNING!
|
| A JBuilder installation could not be found. The project
files
| being created will contain default values.
+--
Reading default project ${jbDefaultProject}
+--
| WARNING!
|
| This project is being configured to use ${jdk}. This
| JDK has not been configured yet in your JBuilder
installation.
| Go to Tools|Configure JDKs.
+--
JBuilder XML Project
I would be interested in any feedback from others using both Maven and
JBuilder on the same projects.
--
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: integrationUnitTest
-Original Message-
From: David Zeleznik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 18, 2003 10:08 AM
To: Turbine Maven Users List
Subject: RE: integrationUnitTest
> I've looked a bit more at our situation. Currently, we have all
> our unit and
> integration tests for a particular project stored in the same directory
> tree. This is a holdover from Ant when we simply ran all the
> tests at night
> via a cron job. So, our unit tests can be considered as a strict subset of
> the integration tests. So, what I am now thinking is that our project.xml
> would contain the fileset definition for all the tests, ie. the
> integration tests. Then we could define a project property that
> contains an
> additional exclude pattern that will refine the integration tests into the
> unit tests. I am not sure if it is possible to modify the pom
> programmaticly, but I am going to try doing something like:
>
>value="pom.build.unitTest.addExclude(myExcludePatternProp)" />
>
> in a test pregoal. This might serve my needs adequately for now.
FYI, I have managed to get the following to work in my test pregoal:
Include var: ${includeVar}
${context.getVariable(includeProp)}
${context.getVariable(excludeProp)}
Therefore, based on the value of test.mode I will use the corresponding
${test.mode}.includes and ${test.mode}.excludes project properties to modify
the jUnit fileset. Right now, we will support just the 2 test "modes", but
this allows flexibility to define additional named test subsets.
--
David Zeleznik
ILOG - Changing the rules of business
mailto:[EMAIL PROTECTED]
http://www.ilog.com
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
