Brett Porter wrote:
no, sorry. The annotations are read from source files, not binaries.
It's possible to post process .class files with BCEL or ASM and add
custom attributes to the classfile elements (fields, methods). AspectJ
does that for one example. At runtime these attributes may be
Vincent Massol wrote:
BTW, I'm not saying this is a terribly intelligent, innovative and
absolutely needed plugin. I'm just recording here as an idea as it may fill
some needs...
Or maybe from another angle - let's make a m2 _daemon_ - a standalone
application that _embeds_ m2. The
David Hawkins wrote:
I created a plugin for dependency management and pom editing via the
command
line.
Cool, but why commandline? Maybe you could get in touch with the
Mevenide team (http://mevenide.codehaus.org/) the integrators of Maven
in the IDEs?
Good luck and thanks for sharing
Jurgen De Landsheer wrote:
Is there a working jalopy plugin for Maven 2.
And if not, do I need to share the one that I created?
http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Matrix
says that there is a feature complete M2 Jalopy plugin.
R.
Brett Porter wrote:
We've set up for testing the following repository for Maven 1.x users:
http://repo1.maven.org/maven
This maps directly onto the Maven 2 repository, converting the layout on
the fly. Being able to do this will reduce the amount of maintenance
required and ensure libraries
Jeff wrote:
(Sorry for my poor english. Hopefully, I'm not as dumb as my english
sound...)
Hey, your English is fine, no need to worry!
The eclipse plugin didn't generate a correct .wtpmodule for me. The
dependencies artifact where not included.
I traced back the problem to the call to
Grzegorz Slowikowski wrote:
Hi
I agree with you. There should be sources archive along with
binaries for every released Maven version, even beta. I don't
think this is to much work. When one builds binaries (probably
Bret does it), he has sources that can be distributed.
Well, you can get the
Andreas Sahlbach wrote:
Because if you cannot provide this, then I really have to assume that,
if I will use maven2 for my projects then I will end up in the same
mess like you. And that's something that every professional software
developer should try to avoid like hell.
Luckily those
Andreas Sahlbach wrote:
The Gentoo guys prefer to build every open source project by
themselves. Besides: building and installing a two, strictly separated
steps, so no writing into the system is allowed (and will be prevented
by the sandboxshell) during the build.
IMHO even if the sources of
Juraj Burian wrote:
We are working on jboss-aop APT plugins implementation.
We encountered the folowing problem (in general):
We need to split classpath into several parts. In other words, we need
to group dependencies.
For example, when running JBoss AOP it is necessary to supply classpath
Mauro Botelho wrote:
The eclipse plug in seems to check if it is running in reactor mode, and
if it is it will then accumulate sources and artifacts/dependencies to
generate a single project.
Well it apparently generates 1 eclipse project for 1 m2 project in
non-reactor mode. I'd be much
[ http://jira.codehaus.org/browse/MNG-955?page=comments#action_48424 ]
Rafal Krzewski commented on MNG-955:
Using eclipse project references is the right thing to do in 99% cases IMO. It
gives you point-and-click navigation over the up-to-date sources
Juraj Burian wrote:
For example, when running JBoss AOP it is necessary to supply classpath
where aspects are found and a different classpath where classes that
should be weaved are (ie. 2 different classpath).
We can see 2 possible solutions:
1) Adding properties to dependency (as in
Mauro Botelho wrote:
It makes sense, but in what cases would that code be activated then?
If you run m2 eclipse in the top level directory it will successfully
generate project descriptors in level 1 subdirectories that contain Java
(jar) projects. These can be imported into an eclipse
[ http://jira.codehaus.org/browse/MPEJB-22?page=comments#action_45927 ]
Rafal Krzewski commented on MPEJB-22:
-
priority should be minor, simple workaround exists which is using
typeejb/type in dependency declaration
generated client jars are placed
Vincent Massol wrote:
If I had to choose between the 3 I'd say 31. I find 32 and 33 too heavy in
colors and I prefer simplicity.
Same for me. 31 or even lighter than that.
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
John Fallows wrote:
Is it always considered a build failure if integration tests do not pass 100%?
I did you mean acceptance tests?
In my understanding integration tests should pass 100% each time they
are run. The difference between unit and integration tests is only in
granularity. Unit
[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42867 ]
Rafal Krzewski commented on MNG-521:
Please keep in mind that Eclipse does not allow nesting projects. It is
possible to have a signle Eclipse project containg a whole Maven project
[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42872 ]
Rafal Krzewski commented on MNG-521:
I would really prefer to change it manually in a single file, than ask a plugin
(or whatever) to roam my workspace and update the poms.
I had
[ http://jira.codehaus.org/browse/MPXDOC-153?page=comments#action_42697 ]
Rafal Krzewski commented on MPXDOC-153:
---
I run into the same problem after upgrading to 1.1-beta-1, which includes
xdoc-1.9.1 plugin.
My brief investigation shows
[ http://jira.codehaus.org/browse/MPARTIFACT-54?page=comments#action_42534
]
Rafal Krzewski commented on MPARTIFACT-54:
--
1.5.2 build is definetely hosed. It was compiled against
org.apache.maven.project.Dependency class that had method
Matthew Pryor wrote:
So I can see how a custom lifecycle is defined implemented, but clearly
having to modify maven-core/META-INF/components.xml to get my
lifecycle/packaging registered is BAD
Definetely.
Since the developers didn't pick up the discussion, maybe you should
file a Jira
Matthew Pryor wrote:
side-note
I suppose I could go down the path of trying to treat the
Eclipse specific stuff as real dependencies and create artifacts for them
and write a custom artifact handler that could read them from the Eclipse
plugins folder, but I think that would be a
Carlos Sanchez wrote:
eg. we require that if you have a foo.com domain your groupId is
com.foo but after that it's up to you. If you have a foo.sf.net we
require net.sf.foo but no more than that.
I like this one very much. It's in-line wit Sun's guidelines for package
names, and provides a
[ http://jira.codehaus.org/browse/MAVEN-1294?page=comments#action_38868 ]
Rafal Krzewski commented on MAVEN-1294:
---
This is excelent news!
Is there any chance to take advantage of fixed Jelly in Maven 1.0.x stream?
Maven is leaking much memory
Vincent Massol wrote:
Why not hand over the plugin to them right now? And if they don't
use/like/care about Maven now, will they in the future?
Maybe they don't and they won't but why is that a problem?
snip
I have no problem at all with this plugin being hosted in maven-plugins
proper. I'm
Vincent Massol wrote:
Please note that in due term, I'd like the Abbot team to take ownership
of it and at that time move it to the Abbot project itself (in the same
fashion as it happened for the statcvs plugin).
Why not hand over the plugin to them right now? And if they don't
use/like/care
Brett Porter wrote:
Hi,
Apart from the documentation that I am working on at the moment, is there
anything else that needs to be completed for Maven 1.0?
I'm sorry I haven't wrote about it earlier but I have been really busy.
I did some testing regarding
Heritier Arnaud wrote:
It's effectively a big problem.
The last time I generated the doc for all maven-plugins, I needed 1Gb of memory !!
I cannot generate full docs for Objectledge, no matter how much -Xmx I
give. Instead of OutOfMemory error, I get IOException: cannot allocate
memory when
Jason van Zyl wrote:
The new xdoc plugin is deadly fast and if you want to do a little
experimenting I'll give you a copy of the new xdoc plugin that you can
try with your Objectledge project. Many of the m1 plugins are going to
die a quick death at the hands of well tested m2 plugins that can be
Heritier Arnaud wrote:
+1
Couldn't we also move(/copy :-( ) the changelog:create-cvspass to the scm plug-in.
I think that functionally the create-cvspass is more a scm related function even if it is used for changelog
yup. seems logical.
We could move the changelog:create-cvspass code to
Janne Kario wrote:
What is the status of the Continuum? I tried searching the apache cvs
tree for something that I could play with but was unsuccessful.
Continuum is based on maven2, which is not available for public
consumption yet. I wouldn't expect that Continuum surfaces in any form
before
Vincent Massol wrote:
FWIW, that's what I've done for the Cactus plugin (I've named it
cactus-maven-plugin). But that's because there is only 1 plugin. If I
had more than 1 I would have named it: cactus-tomcat-maven-plugin or
cactus-maven-tomcat-plugin.
I use the same approach:
Vincent Massol wrote:
Isn't it possible that a dual-license project has the dual license
defined in a single license file? Does it have to be in 2 files?
I'd go with a single file. It's just a text file so people can put in
what they need. For example an explaination what parts of the software
[EMAIL PROTECTED] wrote:
o adding John Casey's patch which adds support for maven.xml processing in
maven2 using marmlade which is a Jelly replacement.
+!-- Used to support maven.xml script and goal decorating in general. --
+dependency
+ groupIdmarmalade/groupId
+
Eric Pugh wrote:
Out of curiosity, can Eclipse take in as the source a .tar.gz file? It
seems like what you want is to have the artifacts generated by 'maven dist'
be uploaded, which are either a .zip or a .tar.gz. However, .tar.gz seems
to come in a quarter the size, and if we are downloading
Emmanuel Venisse wrote:
maven.dependency.sources=false should be the default value.
Only developers are interest by sources for debugging.
A few suggestions:
- create a separate goal 'eclipse:get-sources' that will try to download
all the sources for the dependencies that you don't have yet
nicolas De Loof wrote:
I don't think sources are different types from artifact. I consider
them as another view to an artifact, so I think they should share the
same artifact-type dir. You should consider the same situation about
md5 checksums.
artifactId.jar - artifactId.jar.md5
First, congratulations everybody (especially Brett) on pushing RC2 out
the door!
Second, I'm wondering what is the status of the HEAD and MAVEN_1_0 branches?
What is going on where, what has been merged where and which one should
be used by people who wish to use and test the test greatest
Maczka Michal wrote:
So what I am saying is that we should be only merging POMs not arbitrary XML
Very good point. I personaly hate SGML entities mockery with all my
heart - it's so ugly and so fragile! As for explicit inclusion of XML
bits, problems arise when they are used acorss multiple
Howdy,
Maven HEAD does not compile for me this morning, apparently due to
missing xmlpull dependency. A part of bootstrap output below:
R.
[echo]
[echo]
+--+
[echo] |
|
[echo] | R U N N I N G B O O T S T
[EMAIL PROTECTED] wrote:
Maczka Michal [EMAIL PROTECTED] wrote on 05/02/2004 09:59:36 PM:
For example if cactus test cases were kept in separate, dedicated
project
this particular problem will almost disappear.
We do exactly this at the moment for our J2EE apps.
I should probably
Hi,
I've run into a weird problem in site generation recently.
When dashboard report is enabled in a my project, xdoc:jelly-transform
writes the html files into
$MAVEN_HOME/plugins/maven-dashboard-plugin-1.3-SNAPSHOT/target instead
of the projects target/docs directory.
From what I've been able
Martin van den Bemt wrote:
It just hit me, a solution for this can be to generate a faq page with
links to all faq pages found (if there are multiple).
Is that usefull ?
It sure sounds so. The link to that page could probably live under
'project information'.
Or should we just remove the
Jason van Zyl wrote:
plugin:deploy sounds like it should deploy to the remote repo. Is there
no plugin:install for just doing things locally?
General contract was that type:install would deploy the artifact into
the local repository. plugin:install does that, plus it installs the
plugin into
Emmanuel Venisse wrote:
+1 for rename actual deploy to unpack
+1 for deploy on remote repo
ditto.
Did you notice that the plugin:install goal also does something
different than (jar|war|ear):install goals?
What I'd like best would be full suite of deployment goals (install,
install-snapshot,
Jason van Zyl wrote:
I think it would be better not to mess with it right now. But it's a fine
goal for a cleaner bootstrap - the bootstrap ant task can just pull down the
JARs from the repo.
The bootstrap can just run the reactor in ../maven-plugins instead of
src/plugins-build. I would just
Vincent Massol wrote:
artifactId-version.jar
artifactId-src-version.zip
artifactId-javadoc-version.zip
etc
We *could* standardize on artifact names of course. The artifactId
could be optional and default to ${pom.artifactId}:
tweaking the above a bit:
artifactId-version.jar
Vincent Massol wrote:
I would be -1 to change the standard naming of
name-version.extension.
I think its a minor change if you look at it in the following way:
name-versionextension
old extensions: .jar .zip .war ...
new extensions: .jar -debug.jar -source.zip ...
Could you explain why you
Christian Andersson wrote:
I've made a small rmic plugin for my own usage (with some help from
within here)
what it does is that it searches all compiled classes from your project,
and locates every class that implements the java.rmi.Remote interface,
the class cannot be an interface or
Luke Taylor wrote:
I've just realized that this is more complex than I thought. You can't
combine cvs log output by concatenating. To take advantage of that the
revision information would have to be stored in a processed from, to
faciliate reading it, combining and storing again.
That's
Rafal Krzewski wrote:
Saving the bandwidth is definetely a good thing. I'm wondering if it is
possible to avoid downloading a complete log file on each run. I imagine
that if you saved the login in ~/.statcvs along with a timestamp, and
use a cvs log -D on the next run you could just combine
[EMAIL PROTECTED] wrote:
The idea is that the user knows what he wants, not the project builder.
I thought that the difference between project.properties and
build.properties was the the former were created by the project's
vendor and the latter by the person who is building the project
and are
[EMAIL PROTECTED] wrote:
I can just see the IDEA, JBuilder and JDeveloper files getting checked
into CVS too
How about including all the IDE specific files into the
CVSROOT/cvsignore file? I think you guys forgot about this feature of
CVS :-)
R.
[EMAIL PROTECTED] wrote:
I'm ok with it happening before rc1.
It's 'just another plugin', and we now have ways of getting plugin
releases easily.
Actualy, it's an upgrade to a plugin that already exists in Maven
distribution. The statcvs plugin can be safely scrapped when statcvs-xml
is
Vincent Massol wrote:
Hi guys,
The statcvs team has done a wonderful job of outputting statcvs reports
in XML (this was a request I had opened some time ago so that we could
further integrate statcvs reports with the Maven look and feel and
they've implemented it!).
The result is available at:
Vincent Massol wrote:
However, as Jason pointed out, I agree that we can do it in 2 steps.
Step 1, keep the core plugins in Maven core while moving others out.
Step 2, separate all plugins from Maven core.
I don't think we should ever go to step 2. Some of the plugins are
*required* to build
Vincent Massol wrote:
I'd like to understand (I guess I should read the build script code).
Could you please describe in more details why we would shoot ourselves
in the foot?
First off, you should watch closely the messages that show up during the
bootstrap. The last phase is Building Maven
Vincent Massol wrote:
Why? You're making the assumption that the plugins are part of Maven
core! However, if you consider that Maven core is not about the plugins,
then, you don't care if the plugins come in binary form. Same as you
don't want to build jelly from the source, right?
I think
Norbert Pabi wrote:
Yes.
You said you don't want users to have 20 dependencies in project.xml.
I do not want to have any. If there will default project.xml with
preferred versions
with a possibility to change it - that sounds good to me.
Sounds interesting, but it's rather hard to achieve.
Thiago Leão Moreira wrote:
I am a Maven's user and I work with J2ME plataform. I wrote plugins
to improve the process of development of J2ME software. So I would like
to add these plugins in Maven distribution. How can do this
Maven wiki has some helpful infomration:
[EMAIL PROTECTED] wrote:
Index: plugin.properties
===
RCS file: /home/cvs/maven/src/plugins-build/war/plugin.properties,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- plugin.properties
Hi,
I have a question regarding line #445 in PluginManager.java. It sets the
context class loader to null. For some reason that I can't grasp at the
moment it does not cause breakage when Maven is being run from the
command line. While running under Eclipse's debugger however, this
causes the
Martin Skopp wrote:
dion, rafal, I understand right:
You prefer to NOT used the -w (= --ignore-all-space ) option, right?
I never use -w, makes the diffs bigger but then I can be sure that files
are byte-for-byte identical.
R.
Hi everyone, I'm back from vacation. I've just tried bootstraping HEAD
and got the following two test failures:
Testcase: testMakeAbsolutePath took 0.056 sec
FAILED
Check windows relative path expected:...\src\test\basedir\... but
was:.../src/test/basedir/...
Eric Pugh wrote:
Findbugs is licensed under LGPL.. Does this mean the plugin could NOT go in
the maven core due to Apache licensing?
Yes, the policy is that no source code in ASF projects may compile- and
link-depend on GPL and LGPL code. Therefore your plugin can't go into
maven repository.
John Farrell wrote:
Hi all. I am a new Maven user. I believe I have tidied up and improved the
junit report page. To whom do I send my changes? Thanks,
You should create an 'Improvement' issue in Maven's Jira, describe what
you did, and attach a patch (in unidiff format) to the issue. If your
[EMAIL PROTECTED] wrote:
I've added the ability for normal jira users to edit the issues.
That will certainly make nominating bugs easier, but on the second
though is this a good idea in the long run? Sheduling isssues is
the responsibility of the development team, not the users.
We can try how
Rafal Krzewski wrote:
[EMAIL PROTECTED] wrote:
I've added the ability for normal jira users to edit the issues.
That will certainly make nominating bugs easier, but on the second
though is this a good idea in the long run? Sheduling isssues is
the responsibility of the development team
James CE Johnson wrote:
ejbdoclet ... lots of attributes
... lots of common stuff like session/
jboss subtask /
/ejbdoclet
Then in weblogic:ejbdoclet you would have this:
ejbdoclet ... lots of attributes
... lots of common stuff like session/
weblogic subtask /
Kaus Olaf wrote:
Hi Maviacs,
I am a newbie in the OpenSource-Business and I would like to support the community.
I fix the Bug ISSUE: (MAVEN-540) Property: maven.plugin.dir doesn't work,
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-540
but I don't know how to submit the patch.
Willie Vu wrote:
Attached is a patch to fix the problem.
Please, please post patches to Jira. That makes the life of maintainers
a lot easier, and gives you the best chance of getting your patches in.
R.
-
To unsubscribe,
Anton Tagunov wrote:
Hi, All!
1. year - date
2. make section ordering uniform:
let jar:deploy-snapshot come after jar:deploy
like jar:install-snapshot comes after jar:install
Please post patches to Jira, they're very likely to go unnoticed
otherwise.
Thanks for your
Vincent Massol wrote:
Hey, I am very interested... :-)
I'm monitoring closely your work on generating maven xdocs from moinmoin
and using CVS as the backend storage! You're working on that, right? :-)
Editing (a part of) project's xdocs using a Wiki interface seems to be a
wanted feature
Mark H. Wilkinson wrote:
I'm wondering if there's a fundamental reason why we couldn't change
maven to build a dependency graph of files with scripts attached to the
arcs, just like make used to do. Statements and scripts would need a way
to expose the lists of source files and target files to
Michal Maczka wrote:
For the moment I have tested my API with username, user password
kept in properties file. I think such approach is not acceptable.
You can use command line to pass properties to maven:
maven war:deloy -Dmaven.repo.ibiblio.password = **
This is already better
Dima Berastau wrote:
Hi Everyone,
Attached are maven ejb, war and ear plugin patches, based on a 2 weeks old
discussion on maven-users (titled 'j2ee workflow' if I remember correctly).
I was hoping to get this emailed earlier but got caught up with other
things.
You need to post your
Jason van Zyl wrote:
There will no longer be any namespace confusion as what's in a plugin is
completely separate. You could have the same property in many plugins
now and the value for the particular plugin will stay attached to the
plugin it belongs too. There are now separate classloaders
[EMAIL PROTECTED] wrote:
I've just added this plugin as it has come in handy when working with
multiple projects in my day job.
I haven't yet add the site aggregation I was hoping to have done by now.
The plan is to allow for multiple strategies for implementing site
aggregation:
1)
[EMAIL PROTECTED] wrote:
We also need it for documentation. Its quite common for people to ask
'what property do I set to do' because there are so many
undocumented properties. If there was a metadata file that described
plugin properties, it could be used to generate the xdocs.
There
[EMAIL PROTECTED] wrote:
Added: src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
SFtpDeployer.java
Removed: src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
SshDeployer.java
Log:
Changed
Jason van Zyl wrote:
On Tue, 2003-06-24 at 18:39, Rafal Krzewski wrote:
[EMAIL PROTECTED] wrote:
Added: src/plugins-build/artifact/src/main/org/apache/maven/deploy/deployers
SFtpDeployer.java
Removed: src/plugins-build/artifact/src/main/org/apache/maven
[EMAIL PROTECTED] wrote:
It would be nice if one of the commiters checked in a plugin-map.xml
xdoc that would contain a list of plugins similar to that one above, and
then all commiters would add their name next to the plugins they are
willing to work on, and their name in ( ) next to the
Mouttet Christian wrote:
Hi all,
can someone tell me why the war:war goal builds a WAR file named
${pom.artifactId}.war? I expected ${maven.final.name}.war as name
like jar:jar builds JAR files.
Unfortunately war plugin is much unlike jar plugin... Michal is working
ATM to bring the
Michal Maczka wrote:
Does anybody has something against building war ___always__ in two distinct
steps?
a) copying to build area (somewhere in target/ )
b) making a jar archive
Go for it - it seems to simplify things, and people might want to run
their application off that exploded
Konstantin Priblouda wrote:
I'm not sure that war artifact always needs version
name on it. Well, from one point of view it would be
nice to have versioned one if we are assembling ear.
But from other point of view if we just assemble web
app
versioned war is not cool...
IMO a war should
Is there some sort of recommendation for that in the W3C Schema papers?
If there is, let's follow it. Otherwise, we could look at xml files up
there on the web and look for common patterns for them.
-
To unsubscribe, e-mail:
Jason van Zyl wrote:
Document it and it will more than likely be followed.
I wish it would be so simple. Humans are lazy and forgetful, even the
best documenation won't change that. The most common case is that some
a person wants to apply just a tiny little fix to a plugin.
I think that
I tried to build maven-new and I got this:
[junit] Running
org.apache.maven.artifact.factory.DefaultArtifactFactoryTest
maven.repo.local = ${maven.home}/repository
artifact factory : mavenRepoLocal = ${maven.home}/repository
artifact factory : mavenRepoLocal = ${maven.home}/repository
Ben Walding wrote:
This stuff is in so much flux that I'd expect tests to fail on a regular
basis. That being said, attaching the output of test results would be a
good start.
target/test-reports/whichever ones failed
Ha! Didn't know about that one... (I'm not using Junit in my project
yet,
Michal Maczka wrote:
My repository path does not start with ${maven.home}...so this problem did
not show up.
I have something like:
/repository
/maven
It seems like interpolation problem.
I have a question: What is the proper way of building maven-new?
It is not self hosting AFAICT,
91 matches
Mail list logo
