Re: Please make "sources" jar available to Maven1 users
I can't select "Maven Project Administration" in Jira "create bug" page :
http://jira.codehaus.org/secure/CreateIssue!default.jspa
BUT I can search for issues on this project... Is this a JIRA
configuration bug ? Would I create a Jira Issue about Jira config ;-)
Nico.
Brett Porter a écrit :
Please put it in JIRA under the project MPA (Maven Project
Administration) - thanks.
Nicolas De Loof wrote:
I've found it myself in maven SVN :
(maven/components/trunk/maven-meeper/src/bin/ibiblio-htaccess)
The current rewrite rule converts
group/java-sources/artifact-xyz-sources.jar
to
group/artifact/artifact-xyz-java-sources.jar
So I can see three options :
1. Add a new Rule for "java-sources" :
RewriteRule
^([^/]+)/java-sources/([^0-9]+)-([0-9].+)-sources\.([^0-9]+)(\.md5|\.sha1){0,1}$
r/$1/$3/$4/$3-$4.$5$6 [PT]
2. Change the existing rules to ignore the "java-" prefix in
"java-sources", something like this :
RewriteRule
^([^/]+)/(java-)?(jar|pom|config|distribution|source|dist|...
3. Update maven1 source-plugin to use "sources" as artifact type, and
also update IDE plugins (eclipse, idea...)
3-bis : change maven2 repo and pluins to use
artifact-xyz-java-sources.jar as sources jar
Please can any commiter take a look at this ?
Nico.
Nicolas De Loof a écrit :
Hello guys,
From a previous post I know Maven1 repo is a redirect to maven2
repository content, with path transcripted to match maven2 hierarchy.
commons-collection (as an example) has sources jar in maven2 repo
(http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.1/commons-collections-3.1-sources.jar),
but I cannot get them using maven1 from
http://www.ibiblio.org/maven/commons-collections/java-sources/commons-collections-3.1-sources.jar
Maybe a new Apache rewrite rule may be required for this.
I would also be very interested if someone can give me the rewrite
rule used on ibiblio to convert m1 dependency path to m2 repo
hierarchy.
Nico.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify
the sender immediately and delete all copies of this message.
-
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]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven-idea-plugin
In a multi-module project you might be right that grouping by scope is not the
easiest way to group. However, we might consider creating groups for each
module and for each scope, i.e. in a project with three modules data, logic,
mvc. We might create the following list of project libraries:
- data-compile, data-runtime, data-test, etc.
- logic-compile, logic-runtime, etc
- mvc-compile, etc
- ${artifactId}-compile, etc.
Roald Bankras
Software Engineer
JTeam b.v.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
I don't agree with grouping by scope (that likely wouldn't work if I
understand correctly, as the project libraries would be different for
every module), but by groupId might as an optional configuration option.
Please put it in the JIRA.
- Brett
Roald Bankras wrote:
> Hi all
>
> Are there yet any plans to group the dependencies inside intellij?
> I'd like to see some project libraries instead of module libraries. My
> suggestion is to group them by scope, but another way might be to group them
> by module (esspecially for multi module projects).
> What are your idea's?
>
> Roald Bankras
> Software Engineer
> JTeam b.v.
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.6/339 - Release Date: 5/14/2006
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please make "sources" jar available to Maven1 users
Please put it in JIRA under the project MPA (Maven Project
Administration) - thanks.
Nicolas De Loof wrote:
I've found it myself in maven SVN :
(maven/components/trunk/maven-meeper/src/bin/ibiblio-htaccess)
The current rewrite rule converts
group/java-sources/artifact-xyz-sources.jar
to
group/artifact/artifact-xyz-java-sources.jar
So I can see three options :
1. Add a new Rule for "java-sources" :
RewriteRule
^([^/]+)/java-sources/([^0-9]+)-([0-9].+)-sources\.([^0-9]+)(\.md5|\.sha1){0,1}$
r/$1/$3/$4/$3-$4.$5$6 [PT]
2. Change the existing rules to ignore the "java-" prefix in
"java-sources", something like this :
RewriteRule ^([^/]+)/(java-)?(jar|pom|config|distribution|source|dist|...
3. Update maven1 source-plugin to use "sources" as artifact type, and
also update IDE plugins (eclipse, idea...)
3-bis : change maven2 repo and pluins to use
artifact-xyz-java-sources.jar as sources jar
Please can any commiter take a look at this ?
Nico.
Nicolas De Loof a écrit :
Hello guys,
From a previous post I know Maven1 repo is a redirect to maven2
repository content, with path transcripted to match maven2 hierarchy.
commons-collection (as an example) has sources jar in maven2 repo
(http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.1/commons-collections-3.1-sources.jar),
but I cannot get them using maven1 from
http://www.ibiblio.org/maven/commons-collections/java-sources/commons-collections-3.1-sources.jar
Maybe a new Apache rewrite rule may be required for this.
I would also be very interested if someone can give me the rewrite
rule used on ibiblio to convert m1 dependency path to m2 repo hierarchy.
Nico.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential
and is the property of the Capgemini Group. It is intended only for the
person to whom it is addressed. If you are not the intended recipient,
you are not authorized to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive
this message in error, please notify the sender immediately and delete
all copies of this message.
-
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: maven-idea-plugin
I don't agree with grouping by scope (that likely wouldn't work if I understand correctly, as the project libraries would be different for every module), but by groupId might as an optional configuration option. Please put it in the JIRA. - Brett Roald Bankras wrote: Hi all Are there yet any plans to group the dependencies inside intellij? I'd like to see some project libraries instead of module libraries. My suggestion is to group them by scope, but another way might be to group them by module (esspecially for multi module projects). What are your idea's? Roald Bankras Software Engineer JTeam b.v. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
2.1 Design and Process
Hi, Responding to Trygve and Kenney from here (beaver suffered an outtage). Just looking at the PEPs (http://www.python.org/dev/peps/) and looks like a good idea. They have templates and my argument for the same format is the historical success of couching problems a la The Pattern Language as it has been successful in architecture and in software development (Design Patterns). We could have a template for improvements to make it easy to add enhancements requests. But whatever the format the design/enhancement takes I think the queue is more important here. The form of the request can adapt but making everyone focus on the issues, the format can adapt to what becomes most useful. I just use A Pattern Language as it is a successful precedent to follow. I agree that whatever we come up be applied to all the projects. As far as being able to edit designs is good, it's just the focus is on the issues in the queue. As far as implementation I think a wiki page pointing to the five issues in the queue would be fine. Would be nice to have nice linking between doco and issues generated from design ideas but JIRA/Confluence are just too crappy to try and implement this without crying. I think a simple list is fine, when you've had your issue resolved edit the list and take it out and let someone else add one. I think we can integrate the categories that we have on the design issues page, and there is still a disconnect between what's in the wiki and what's in JIRA. So hopefully there will be some more feedback and I will start modifying what's there and try to move toward something we can use for next week. I think just the queue is a good idea. BTW, a bunch of us are getting together in LA next week to discuss some design issues so if anyone is interested in joining us (myself, brett, john, jesse, carlos, joakime) you are most welcome. We'll have whiteboards, lots of ideas and we'll feed anyone who shows up :-) jason.
Re: 2.1 Design and Process
On 5/15/06, Jesse McConnell <[EMAIL PROTECTED]> wrote: I think this is a great idea, it would be a good exercise to go through the existing ideas that are slated and clean them up in a clear well reasoned way. the limited amount in the queue at any one point in time is probably a good idea as well...force the asking of the tough questions and whatnot.. I think the stuff has to be collected and sorted to see what we have as stuff is just all over the place. I can see the issues say for "Dependencies" in JIRA but that's not related to anything in the wiki. Right now we have lots of JIRA issues for design, and documents in the wiki, and probably some stuff in APT in SVN. Right now there are a set of components in JIRA (http://jira.codehaus.org/browse/MNG) and a set of categories in the wiki ( http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents) and they don't mesh. I would like to sync those first and the components in JIRA, I think, should be the definitive list and we should use the components (like Dependencies) when talking about a design issue. is that things just get kicked up on the mailing list and then disappear down on the list to atrophy. should there be an attempt to clear one or two MEPs a week? :) Right, things on the mailing tend to peter out. The tendency should shift to trying to help resolve the issues in the queue before work begins on any new ideas. People who took the time to write up a design and put it in the queue should have a the required audience to resolve the issue. The only discussion about design that crop up on the list should be the ones in the queue, everything else gets written up and gets in line for entrance into the queue. Would be nice to have a few MEPs resolved a week but whatever it ends up being the queue becomes the only place to go in the short term. So someone who put in the effort doesn't get drown out on the mailing list. I'm going to try and align the components in JIRA with the categories in the wiki and try some ruby junk today and see what falls out. jason. jesse On 5/15/06, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: > Jason van Zyl wrote: > > Hi, > > > > I was just looking at the wiki for the 2.1 design stuff and was > > wondering if we could use a common format for each issue? I was > > thinking that we may borrow from a Pattern Language and for each issue > > have a Context, Problem, Solution, and maybe Implementation Details. > > So for something like having selectable project builders based on version: > > Not sure if it's apropriate for us, but Python has a similar mechanism > called Python Enhancement Proposals (PEPs)[1]. They don't have the same > layout for all the requests, but they have a set of states for each > proposal. > > I think this is a process that should outlive Maven 2.1 and should cover > all parts of The Maven Project (where Maven the Tool is one sub-project). > > Just might be worth taking a look at for ideas. > > [1]: http://www.python.org/dev/peps/ > > -- > Trygve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 Design and Process
I think this is a great idea, it would be a good exercise to go through the existing ideas that are slated and clean them up in a clear well reasoned way. the limited amount in the queue at any one point in time is probably a good idea as well...force the asking of the tough questions and whatnot.. any idea how the resolution process will go? part of the problem now is that things just get kicked up on the mailing list and then disappear down on the list to atrophy. should there be an attempt to clear one or two MEPs a week? :) jesse On 5/15/06, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: Jason van Zyl wrote: > Hi, > > I was just looking at the wiki for the 2.1 design stuff and was > wondering if we could use a common format for each issue? I was > thinking that we may borrow from a Pattern Language and for each issue > have a Context, Problem, Solution, and maybe Implementation Details. > So for something like having selectable project builders based on version: Not sure if it's apropriate for us, but Python has a similar mechanism called Python Enhancement Proposals (PEPs)[1]. They don't have the same layout for all the requests, but they have a set of states for each proposal. I think this is a process that should outlive Maven 2.1 and should cover all parts of The Maven Project (where Maven the Tool is one sub-project). Just might be worth taking a look at for ideas. [1]: http://www.python.org/dev/peps/ -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please make "sources" jar available to Maven1 users
I've found it myself in maven SVN :
(maven/components/trunk/maven-meeper/src/bin/ibiblio-htaccess)
The current rewrite rule converts
group/java-sources/artifact-xyz-sources.jar
to
group/artifact/artifact-xyz-java-sources.jar
So I can see three options :
1. Add a new Rule for "java-sources" :
RewriteRule
^([^/]+)/java-sources/([^0-9]+)-([0-9].+)-sources\.([^0-9]+)(\.md5|\.sha1){0,1}$
r/$1/$3/$4/$3-$4.$5$6 [PT]
2. Change the existing rules to ignore the "java-" prefix in
"java-sources", something like this :
RewriteRule ^([^/]+)/(java-)?(jar|pom|config|distribution|source|dist|...
3. Update maven1 source-plugin to use "sources" as artifact type, and
also update IDE plugins (eclipse, idea...)
3-bis : change maven2 repo and pluins to use
artifact-xyz-java-sources.jar as sources jar
Please can any commiter take a look at this ?
Nico.
Nicolas De Loof a écrit :
Hello guys,
From a previous post I know Maven1 repo is a redirect to maven2
repository content, with path transcripted to match maven2 hierarchy.
commons-collection (as an example) has sources jar in maven2 repo
(http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.1/commons-collections-3.1-sources.jar),
but I cannot get them using maven1 from
http://www.ibiblio.org/maven/commons-collections/java-sources/commons-collections-3.1-sources.jar
Maybe a new Apache rewrite rule may be required for this.
I would also be very interested if someone can give me the rewrite
rule used on ibiblio to convert m1 dependency path to m2 repo hierarchy.
Nico.
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not
the intended recipient, you are not authorized to read, print,
retain, copy, disseminate, distribute, or use this message or any
part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: multi-project pain
> First thought: Why "modules"? Everyone talks about > "multi-projects" and "artifacts" I try to avoid calling it multiproject for this reason. So how do you call it then? ;) > When I tried to build the (main) project I got told off that packaging > was meant to be "pom" not "jar" ...ok - but why? Currently, there's no real concept of aggregation in the standard packaging plugins, so it makes no sense to have a build root with a type other than pom. I meant: why shouldn't also the parent pom have a src directory and generate a jar? I don't understand the concept of this distinction that forces me to have all my code in modules. > So I ended up creating another "test" modules that depends on core and a > compiler implementation. Ok. Not fantastic but works. Well ...maybe > not a bad idea in the end anyway. This is a pretty common pattern. What is your API doing that it needs an implementation to test it? How do you differentiate testing the API from the implementation? I think it's a good practice to separate them. Yes, in the end having the test separate is maybe not that bad at all. What I am actually trying to test is the monitoring, notification and the reloading ...which is triggered by a compilation. Of course I *could* mock a compiler ...but that's a bit of an effort. Maybe I will do it at some stage. It would be cleaner - but so far the testcases just use one of the implementations. > "What is this skin plugin thingy?" Confused. Ok. Different approach. That stuff is new, and only released as a beta yesterday. I tried to include some docs in the site, but it probably needs some more. Cool ...nice to have a beta out :) > Although I really hate to move the documentation and the site into the > core sub-project I gave it a try. So the idea is that the core site > will become the main site. If I don't get the reports for the compiler > sub-projects well, I could live without them - they are only > wrappers. But this sucks! But let's try it. You lost me here as to why moving it to the core project was even necessary. I did not want the reports to run for every module so I just picked one of the modules to build the site. I would have to change into that directory and build the site from there. Not nice. Also did not stick with it. I wouldn't recommend moving the whole site into the core project - you should be able to build all your reporting sections as part of a reactored site, possibly aggregating some as I think you've since discovered. Yepp ...finally :) However, I recommend the content goes into a separate parallel directory. (See chapter 6 of the book). Aha must have missed that one - will have a read. > So I moved all the reports from the parent pom into the core pom. No > defined reports for the parent, nothing to inherrit to the > sub-projects and I will just define my site in the core. I expected > that a call to site will just get ignored by the parent and passed on > to the core site goal which will do the actual work ...but now > -although I haven't defined a single report- a whole bunch of reports > (more than I ever had defined) get generated for the parent pom - WTF? Can you give more details? The only default reports should be the project info reports. Well more than I expected ;-) IMO there should be no default reports. Too much magic. Keep it simple. If it's not in the pom - it does not appear. > http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk/ Did you since get this sorted or still need help? Well, I finally got it working ...somehow http://jakarta.apache.org/commons/sandbox/jci Not perfect - but a first page that I can update. Still if you could spend 2 minutes having a look at the layout and the pom ...would be really appreciated. AND!! Please (with sugar on top!) ...I need the these two patches applied http://jira.codehaus.org/browse/MPMD-28 http://jira.codehaus.org/browse/MTAGLIST-6 as creating the site currently only works with my locally patched plugins. Next big thing would be aggregation support for the surefire plugin. Does anyone have that on his cards yet? > And BTW: > > On the front page "Information for Maven 1.0 Users" should include a > link to > > http://maven.apache.org/guides/mini/guide-m1-m2.html done. Cool > You guys should also provide a stylesheet for migrating at least > something from the project.xml to the pom.xml. We actually have code to do it in the sandbox. Nobody has pushed it into a plugin yet though. Whatever ...link that stylesheet from the upgrade guide. Maybe someone comes up with a plugin. If not one can at least use xsltproc for the easy upgrade. > And IMO maven is way too verbose. Guys you are talking to a user. > "[INFO]" and stuff like that is good for log a file but not for a user > output. If you output less you could also get rid of some of the Agreed. Great :) > Puuh! Thanks for listening ...feels better now :) Good to hear :) ;-) cheers --
Please make "sources" jar available to Maven1 users
Hello guys, From a previous post I know Maven1 repo is a redirect to maven2 repository content, with path transcripted to match maven2 hierarchy. commons-collection (as an example) has sources jar in maven2 repo (http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.1/commons-collections-3.1-sources.jar), but I cannot get them using maven1 from http://www.ibiblio.org/maven/commons-collections/java-sources/commons-collections-3.1-sources.jar Maybe a new Apache rewrite rule may be required for this. I would also be very interested if someone can give me the rewrite rule used on ibiblio to convert m1 dependency path to m2 repo hierarchy. Nico. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven2 Certification at JavaBlackBelt (under collaborative construction)
Hi everyone, Just to let you know that JavaBlackBelt (http://www.javablackbelt.com/) has started a Maven2 certification. I have helped them define the test objectives and I'm marked as the certification lead. There are currently 3 certifications defined (listed at the bottom of http://www.javablackbelt.com/ExamTaskListing.do): * A base one called the "Maven2 Standard Certification" (see http://tinyurl.com/lfxk2) * One called "Maven2 J2EE Certification" which will require to pass the standard certification to get (see http://tinyurl.com/s5hsc) * Another one called "Maven2 Developer Certification" which will also require to pass the standard certification to get (see http://tinyurl.com/rkayw) Right now these certifications are not ready yet and are being built. The nice thing about the way JBB works is that their test/certification creation is collaborative which means that it's the community which provides the questions. It's also the community which validates/approves/rates the question. Another nice thing is that by participating to questions or moderation you win credits which are currently not convertible to gold (that may happen later on as I understand it) but which you can then use to pass other certifications or trade against books in the auction area (http://www.javablackbelt.com/AuctionListing.do). Getting everyone's participation is the best way to ensure that we have a good Maven2 certification and to spread the Maven2 meme. To summarize here's how you could help: * by authoring questions * by commenting/rating existing questions * by commenting on the current categories * by providing any feedback in general Thanks! -Vincent ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendez-vous sur http://fr.yahoo.com/set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-idea-plugin
Hi all Are there yet any plans to group the dependencies inside intellij? I'd like to see some project libraries instead of module libraries. My suggestion is to group them by scope, but another way might be to group them by module (esspecially for multi module projects). What are your idea's? Roald Bankras Software Engineer JTeam b.v. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.6/339 - Release Date: 5/14/2006
Create Maven plugin
I am new to maven and I am currently creating a plugin for building a
particular type of project using Maven 2.x. To acheive this I develop a
plugin based in an Ant mojo.
I would like to have access, in my Ant mojo script, to a XSL file
(transform.xsl) stored into the plugin (at the root repository).
To achieve this i added a ressource to the plugin's pom.xml :
...
.
transform.xsl
...
Then i created a test.build.xml file that looks like this :
And finally, i create a test.mojos.xml that looks like this :
create_export
create_export
true
Generate an export jar of the project.
scriptsDir
scriptsDir
true
./scripts
${scriptsDir}
java.lang.String
The scripts directory.
In this implementation, when i execute my plugin against a project, my
plugin search the transform.xsl file in the project root repository instead
of the plugin root repository like i want.
Could someone telle me why it doesn't work and how i cant access to the XSL
file, please ?
Thanks in advance!
--
View this message in context:
http://www.nabble.com/Create-Maven-plugin-t1619811.html#a4389172
Sent from the Maven - Dev forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE : [vote] maven war 2.0.1
Hi,
User comment : what about http://jira.codehaus.org/browse/MWAR-33 ?
I think if WEB-INF/lib from war dependencies is not by default excluded
can cause some surprises when the war is deployed on a app server.
Because the WEB-INF/lib cab be different from the classpath in the test
cases.
But the others goodies are well.
- Olivier
-Message d'origine-
De : Brett Porter [mailto:[EMAIL PROTECTED]
Envoyé : dimanche 14 mai 2006 22:38
À : Maven Developers List
Objet : [vote] maven war 2.0.1
Maven 2.0 had a fairly decent regression:
http://jira.codehaus.org/browse/MWAR-38
which appears to have been caused by:
http://jira.codehaus.org/browse/MWAR-7 (though the fix should support
both)
I'm surprised nobody noticed this during the testing period. Is nobody
using EJBs any more? :)
Anyway, I've fixed it, and the tests which were asserting the extension
was ".ejb" (I guess I didn't review them closely enough). I think it is
worth releasing after a vote period.
[ ] +1
[ ] +0
[ ] -1
I'd appreciate if folks could test their own projects and see if there
are any other potential fixes that should go in during the vote period.
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, any attachments and the information contained therein ("this
message") are confidential and intended solely for the use of the addressee(s).
If you have received this message in error please send it back to the sender
and delete it. Unauthorized publication, use, dissemination or disclosure of
this message, either in whole or in part is strictly prohibited.
**
Ce message électronique et tous les fichiers joints ainsi que les informations
contenues dans ce message ( ci après "le message" ), sont confidentiels et
destinés exclusivement à l'usage de la personne à laquelle ils sont adressés.
Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur
et de le détruire. Toutes diffusion, publication, totale ou partielle ou
divulgation sous quelque forme que se soit non expressément autorisées de ce
message, sont interdites.
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-jar-plugin fixes to be reviewed committed
On 5/15/06, Brett Porter <[EMAIL PROTECTED]> wrote: Heh, this was 13/4 not 14/5 as I thought. Time flies, right? Are these still needing to be looked at? Yes So here's a little update :) patch management - review MJAR-27 - let me know if you really want a test case or apply. - review MJAR-25 - let me know if we should fix the archiver instead. See also MJAR-7. issue management: - close MJAR-31 (mark as fixed - other issue not reproducible) - close duplicate MJAR-7 - close MJAR-35 (will be fixed in webstart plugin) - close MJAR-4 (PLX-185 was fixed) (or should we wait for feedback?) if you do all this, please upload a new snapshot. Most issues with high priority have been closed. Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] maven war 2.0.1
+0 s/ On 5/14/06, Brett Porter <[EMAIL PROTECTED]> wrote: Maven 2.0 had a fairly decent regression: http://jira.codehaus.org/browse/MWAR-38 which appears to have been caused by: http://jira.codehaus.org/browse/MWAR-7 (though the fix should support both) I'm surprised nobody noticed this during the testing period. Is nobody using EJBs any more? :) Anyway, I've fixed it, and the tests which were asserting the extension was ".ejb" (I guess I didn't review them closely enough). I think it is worth releasing after a vote period. [ ] +1 [ ] +0 [ ] -1 I'd appreciate if folks could test their own projects and see if there are any other potential fixes that should go in during the vote period. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1 Design and Process
Jason van Zyl wrote: Hi, I was just looking at the wiki for the 2.1 design stuff and was wondering if we could use a common format for each issue? I was thinking that we may borrow from a Pattern Language and for each issue have a Context, Problem, Solution, and maybe Implementation Details. So for something like having selectable project builders based on version: Not sure if it's apropriate for us, but Python has a similar mechanism called Python Enhancement Proposals (PEPs)[1]. They don't have the same layout for all the requests, but they have a set of states for each proposal. I think this is a process that should outlive Maven 2.1 and should cover all parts of The Maven Project (where Maven the Tool is one sub-project). Just might be worth taking a look at for ideas. [1]: http://www.python.org/dev/peps/ -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] maven war 2.0.1
+1 Emmanuel Brett Porter a écrit : Maven 2.0 had a fairly decent regression: http://jira.codehaus.org/browse/MWAR-38 which appears to have been caused by: http://jira.codehaus.org/browse/MWAR-7 (though the fix should support both) I'm surprised nobody noticed this during the testing period. Is nobody using EJBs any more? :) Anyway, I've fixed it, and the tests which were asserting the extension was ".ejb" (I guess I didn't review them closely enough). I think it is worth releasing after a vote period. [ ] +1 [ ] +0 [ ] -1 I'd appreciate if folks could test their own projects and see if there are any other potential fixes that should go in during the vote period. - Brett - 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]
