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 acc
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 application
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.
-
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 your
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 arr
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 pr
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
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 problem
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
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
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 Maven1).
[ 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
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 surp
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 works
[ 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
ejb in dependency declaration
> generated client jars are placed in /e
Reporter: Rafal Krzewski
client jars are _not_ ejb modules, but rather utility libraries. they should be
placed in jars directoy, and thus jar dependency type.
I think it was like that around 1.5 release of the plugin, but was (possibly
unwittingly) changed later.
--
This message is
generated client jars violate maven artifact naming convention
--
Key: MPEJB-21
URL: http://jira.codehaus.org/browse/MPEJB-21
Project: maven-ejb-plugin
Type: Bug
Versions: 1.7.1
Reporter: Rafal
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 t
[ 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/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/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 that
[ 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 issu
Matthew Pryor wrote:
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 lot of code
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 go
[ 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 mem
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?
I have no problem at all with this plugin being hosted in maven-plugins
proper. I'm sorry for
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 abou
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
u
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 launc
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
http://jira.codehaus.org/browse/MPMULTIPROJ
Jason van Zyl wrote:
On Tue, 2004-05-25 at 12:05, Vincent Massol wrote:
Hi Carlos,
I still believe we're missing a "local/private" repository kind of stuff
to share non-public data between projects. Or something equivalent.
I honestly don't understand this requirement. What is really the
differen
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 scm:creat
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 ma
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: -maven-plugin. If I
[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.
+
+
+ marmalade
+ marmalade-core
+ 0.1
+
+
+ marmalade
+ marmalade-el-ognl
+
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
a
Hi, for the past few days I was unable to bootstrap 1.0 branch.
Here's the mysterious-looking exception message.
If this does not help, I may try bootstraping off fresh checkout & empty
local repository
[echo] |
[echo] | INSTALLING THE PLUGINS...
[echo] |
[echo]
[exec] _
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.
.jar -> .jar.md5
-src.zip -> -src.zip.md5
Both fil
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 (
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 s
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 Ma
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 p
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 shoul
Stoffels, Ralf (FWI-AW2) wrote:
> Hi,
>
> artifact:install copies the project.xml file without any modifications to
> the repository.
>
> This entails that the extend element looses its reference. Therefore all
> references to the
> extended project (like ${pom.groupId}) are dangling and can't b
Jason van Zyl wrote:
> - include a pointer to an md5 file for the bundle inside the bundle and
> the location must be a public location on the project's site so
> obviously a developer must have access to this site.
>
> - push the bundle to a machine where the md5 file for the bundle can be
> ret
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 :install would deploy the artifact into
the local repository. plugin:install does that, plus it installs the
plugin into MAVE
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 wo
Vincent Massol wrote:
> I would be -1 to change the standard naming of
> -..
I think its a minor change if you look at it in the following way:
-
old extensions: .jar .zip .war ...
new extensions: .jar -debug.jar -source.zip ...
> Could you explain why you think it doesn't belong to the POM?
Vincent Massol wrote:
> -.jar
> -src-.zip
> -javadoc-.zip
> etc
>
> We *could* standardize on artifact names of course. The
> could be optional and default to ${pom.artifactId}:
tweaking the above a bit:
-.jar
--src.zip
--javadoc.zip
or as recently advertised:
--debug.jar
--debug-src.jar
Su
Mark McBride wrote:
> This is true, there's actually only a handful of jars that are actually
> compiled against. The only concern I have with only entering those
> handful of jars as dependencies is that somehow a developer could change
> the version of the jdbc driver not knowing that it has real
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 a
Nathan Coast wrote:
> Hi,
>
> Recently pages generated by site are rendering incorrectly in mozilla.
> I've seen this on pages from maven.apache.org and on local generated
> pages. The lefthand menu is the same width as the header, with the body
> content displayed to the right. A reload fixes
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.
>
>
[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:
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 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 co
Jason van Zyl wrote:
I wanted to get the rationale as to why build.properties from
${user.home} is more dominant than build.properties and
project.properties from the project dir.
From my experience, it is indeed a problem when you need to make
a system specific override for a set of related pro
Tammo van Lessen wrote:
Nope, we introduced the history to provide a (more) correct loc count (and
charts) than the original statcvs does.
cvs log doesnt report the loc of the first revision but the changes for the
following revisions. To get the right loc count, we need to know the count
of the fi
[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:
h
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 thin
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 Mave
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 buil
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 achi
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:
http://wiki.code
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 com
[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.proper
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.
Ralph Apel wrote:
Would it be ok to send
1) cvs diff -u > dotuml.path
2) one jar with sources and configfiles ?
Both would work for a completly new plugin, option 1 should be used
for pretty much everything else.
Instead of sending files to the mailing list, you should raise an
'New Feature' iss
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/...>
junit.framework.Comparison
[EMAIL PROTECTED] wrote:
> After a discussion on IRC with Jason this afternoon I've volunteered to
> roll back CVS Head so it has the pre-refactor code + the changes since,
> until Jason can spend some more time on getting the refactor working with
> all the plugins.
>
> Does anyone have a prob
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
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 i
[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
James CE Johnson wrote:
>
>... lots of common stuff like
>
>
>
> Then in weblogic:ejbdoclet you would have this:
>
>
>... lots of common stuff like
>
>
>
> How do we avoid duplicating all of the common stuff (ejbdoclet attributes
> and subtasks) in an easy to maintain way?
[EMAIL PROTECTED] wrote:
> If you have a fix or a change you would like to be in maven 1.0, please
> ensure that:
>
> 1) It's in Jira
> 2) it's in the roadmap
>
> If it's not, it wont be looked at for the release.
>
> There are a whole heap of bugs listed as unscheduled
>
> These WILL NOT be
Jason van Zyl wrote:
>>I'm confused why they would have come up as mods at all? Usually CVS is
>>smarter than that...
>
> Yes, but Jason is not smarter than CVS :-)
It's sad that a number of bugfixes got rolled back by your commit.
I feel it would be much better if you've done your refactoring
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
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, e-m
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 contr
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 the
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 pa
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
Jason van Zyl wrote:
> On Fri, 2003-06-27 at 03:19, [EMAIL PROTECTED] wrote:
>
>>I've just added this plugin as it has come in handy when working with
>>multiple projects in my day job.
>
>
> How is this different than the standard reactor? Please don't name it
> the reactor as having two entit
[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.
>
[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:
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 classloade
Michal Maczka wrote:
> I have progressed with Deployer API.
Good to hear that. Incosistency among plugins in this regard was a
big drawback IMO.
Everything looks good, but...
#list of repositories to which we will deploy
maven.repo.repos= R1, R2, R3, R4, ibiblio
^
maven.repo.lis
Michal Maczka wrote:
>>I really don't appreciate this kind of name reuse - sftp is a protocol
>>registered by the IETF (tcp/115). It was rather silly of JCraft to use
>>that name for their scp implementation. Let's do better than them and
>>have JavaScpDeployer (and possibly ExternalScpDeployer, if
[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 plugins
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:
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 SCP
1 - 100 of 113 matches
Mail list logo
