Hi!
No one interested?
> Hi!
>
> Given I might find some time I would like to implement the possibility
> to
>
> a) add arguments to the buildcommands.
> b) to define dependencies should be exported
>
> a)
> I would like to archive this by allowing to add a CDATA section to every
> buildcommand i
Issue Subscription
Filter: Design & Best Practices (35 issues)
Subscriber: mavendevlist
Key Summary
MNG-32 Plugin test harness
http://jira.codehaus.org/browse/MNG-32
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
M
I'm not such a fan of classifiers, I'd do a profile triggered by jdk version
1.4
1.3
1.4 and 1.5 support are important, 1.3 depends on what level of detail
you want to go, as you said, maven runs on 1.4+
On 3/17/06, Wayne Fay <[EMAIL PRO
On 3/15/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> Brett Porter wrote:
> > Milos Kleint wrote:
> >> brett, can you point me to the code which you rollbacked? I'd like to
> >> include the rollback into my copy of the embedder artifact I have and
> >> that I plan to include with the next version
I'm not a Maven dev but felt like responding. ;-)
For the MX4J issue... I would build two bundles... One with target
JDK1.4, include the MX4J dependency, and use no classifier... The
other with target JDK1.5 and the classifier jdk5.
This would require people to know to use jdk5
if they are using
Hi all
I have already prepared all poms for Tomcat 5.5.15 artifacts.
I have some questions about dependencies because some things
can be achieved in more then one way and I don't know
which way is the best. I want to discuss a little with maven team
before I give them to Geronimo team.
Where shoul
Hi!
Given I might find some time I would like to implement the possibility
to
a) add arguments to the buildcommands.
b) to define dependencies should be exported
a)
I would like to archive this by allowing to add a CDATA section to every
buildcommand in pom.xml.
So in the end it should look like
If the package of all the classes is com.sun.java.util.collections,
I'd say groupId=com.sun.java.util
On 3/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> For the benefit of legacy code, would the principles outlined in:
>
> http://maven.apache.org/maven-1.x/reference/standard-sun-jar-names.
For the benefit of legacy code, would the principles outlined in:
http://maven.apache.org/maven-1.x/reference/standard-sun-jar-names.html
be extrapolated to cover the
http://java.sun.com/products/archive/javabeans/infobus/collectionsreadme.html
i.e. /com.sun/jars/collections-x.jar
and in gene
It's not really easy to apply the same rules of quality on the main code and
on the tests...
The tests are often very more duplicated (assert.) especially if you
need to use variables. You can find a lot of : assertTrue(result);
I think that we can focus our improvements on the maincode and whe
10 matches
Mail list logo
