Piotr Tabor wrote:
Done: http://docs.codehaus.org/display/MAVENUSER/Maven+Diagram+Maker
I'm not sure that Jimi's license is acceptable according to
http://people.apache.org/~cliffs/3party.html. You would need to get
verification that it's inclusion is approved before using it.
Ralph
Piotr Tabor wrote:
OK. Thanks. In fact I had switched to JAI ( Java Advanced Imaging API
https://jai.dev.java.net/) - but I didn't corrected all places in my
proposal. It's licensed on Java Reasearch License and Java Distribution
License (JDL) https://jai.dev.java.net/jdl-jai.pdf. I don't know
What version of maven are you using?
Ecker Severin wrote:
Hi,
There seems to be no one who can help me in the users list so I hope
that someone around here does haven an idea:
My problem is as follows:
I'm not sure whether I'm not using dependencies correctly or this is a
bug, but the
Kenney Westerhof wrote:
This somewhat describes the situation:
- depMgt for artifact X is used to provide defaults for direct
dependencies of artifact X,
and for overrides of transitive dependencies on X,
unless there's also a direct dependency on X in which case the direct
dependency is
Jason van Zyl wrote:
And I'm still trying to get all the getting prepared for 2.1 before
I start fleshing out any specs. But the artifact resolution in 2.0.x
is fundamentally wrong in not making a graph of the metadata before
the artifacts are materialized so don't be overly surprised if
Harish Kachoria wrote:
Hello All,
I'm trying to integrating Maven in my project.
I was quite comfortable using maven 1.0.
But with Maven 2.0 I have one problem to define dependency of a jar file.
I wants to define dependency without having a version number. how can
I do
that ??
Please
Lukas Theussl wrote:
No, it's still supported and not deprecated in Maven 1.1:
http://maven.apache.org/maven-1.x/reference/maven-model/3.0.2/maven.html#class_dependency
-Lukas
It should have been. I can certainly understand why support for this was
removed in version 2.
Ralph
Brett Porter wrote:
http://maven.apache.org/maven-1.x/faq.html#unversioned-jars
You can name that what you wish in build/deployment/production, they
just need a version in the repository.
Brett, He wants to do this in Maven 2, not Maven 1.
Ralph
+1
Ralph
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 6:44 PM
To: Maven Developers List
Subject: [VOTE] Commit Access for Hervé Boutemy
Hi,
Hervé has been submitting patches on the Maven Ant Tasks for a long
time, done lots of
I met with a group of maven users from several business units of my
company last week. The single largest pain point is still with regard to
dependency management. Despite the changes Patrick and I introduced in
MNG-1577 they are still having difficulties primarily because it is
impractical or
Jason van Zyl wrote:
I have been doing some similar work for a project with 1000+ projects
across 60 branches and I have come to the conclusion that dependency
management via inheritance is ineffective in many cases. Especially
for enterprise wide endeavors.
What people are looking for is
I made a small change to Artifact which is used in maven-project. I then
checked out trunks on another machine and the build failed. When I
manually build artifact first it builds fine. I suspect this is because
artifact was recently split out but was not added as a module to the
main project?
Jason van Zyl wrote:
maven-artifact lives here:
http://svn.apache.org/repos/asf/maven/artifact/trunk/
It is used by maven-project here:
http://svn.apache.org/repos/asf/maven/components/trunk/maven-project/
And maven-artifact in its new separated location is referenced in the
POM of
I made some changes to the dependency management documentation and
checked them in. I tried to rebuild the site but the upload failed with
permission problems. It appears that my id is not a member of the maven
group on people.apache.org. Who has the correct permissions to fix that?
Ralph
Jason van Zyl wrote:
On 23 Sep 07, at 12:20 AM 23 Sep 07, [EMAIL PROTECTED] wrote:
Author: rgoers
Date: Sun Sep 23 00:20:24 2007
New Revision: 578553
URL: http://svn.apache.org/viewvc?rev=578553view=rev
Log:
Allow the managed dependencies of projects to be imported into the
managed
Jason van Zyl said:
On 24 Sep 07, at 9:23 AM 24 Sep 07, Mark Hobson wrote:
Okay, but I do think a feature branch is the best for prototyping new
features - it stops blocking the developer and doesn't cause
unnecessary problems for others. Do we really need to merge it into
2.0.x? 2.0.8 is
OK. My mistake for not making it clear where I wanted to add this. I'll
try to revert this tonight (I'm in California). I'll look at the other
options you've presented for moving this forward.
I should make it clear that I'm not just doing this for my employer (if I
was I'd be doing the work on
I created an issue in Jira but it seems I can't assign it to myself. Can
someone with permission grant me rights to do that?
Thanks,
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
I do not seem to have authorization to edit
http://docs.codehaus.org/display/MAVEN/All+Proposals. Can someone fix that?
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Is there a reason I can't see an edit tab on this page? Can someone
please fix that?
Ralph
Ralph Goers wrote:
I do not seem to have authorization to edit
http://docs.codehaus.org/display/MAVEN/All+Proposals. Can someone fix
that?
Ralph
ralphgoers
Jason van Zyl wrote:
On 11 Oct 07, at 7:03 PM 11 Oct 07, Ralph Goers wrote:
Is there a reason I can't see an edit tab on this page? Can someone
please fix that?
This is the second time I've tried and the user browser is so abysmal
I can't find your user as it just hangs
Jason van Zyl wrote:
Should be good now.
Thanks Jason, but I still don't see an Edit tab on that page. Am I
doing something wrong?
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
I don't know that confluence was designed for debates so I am posting
this here.
Mark, while I appreciate your feedback I have to take issue with the -1.
In all the groups that I work with that use Maven every single one of
the Configuration Management teams that manages the projects requires
-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 11:08 AM
To: Maven Developers List
Subject: Re: [codehaus-confluence] Maven: Importing Managed Dependencies
(Comment Added)
I don't know that confluence was designed for debates so I am posting
this here.
Mark
I've created
http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies.
I'd appreciate feedback on this or its related Jira issue at
http://jira.codehaus.org/browse/MNG-3220. This has become a serious
roadblock in our use of Maven and I would like to resolve it.
Ralph
Jason van Zyl wrote:
I've been working on some release/deployment tools lately for a client
and I modified their deployments so that you could not accidentally
release the same version of an artifact more then once. I can stop
this on the server side only when running a repository manager,
I'll be at ApacheCon.
Ralph
Brett Porter wrote:
I know several folks are presenting and will definitely be there, but
I thought it might be good to send a shout out and see who is coming
along? Hopefully we'll get some opportunities for getting together
around the hackathon/code-a-ramas.
As Brett said this is kind of tough. I work for a large company and if
I had to guess I'd say that the 100 maven users number is being met. But
that is on lots of projects across a fairly large company. Many of these
projects are dependent on each other but are only tied to each other
through
Are there specific examples to illustrate how this works? i.e. are there
unit tests for it? Obviously I'm definitely interested in this.
Ralph
Jason van Zyl wrote:
Mark, Ralph,
You'll probably be interested in the artifact graph code that went in
as the conflict resolution and dependency
+1
Ralph
Brett Porter wrote:
I'd like to call a vote for Nicolas de Loof as a committer, based
primarily on his work for Archiva, but also from being active in the
general Maven community for quite some time. He has been relentlessly
testing and identifying issues and providing patches
Interesting idea, but wouldn't it make more sense to have a separate
plugin that only makes you accept the license when you download the
artifact from the remote repository? If I'm not using a repository
manager and am downloading from from maven.org that might be nice. Once
it is an internal
If you have a super pom that all your projects inherit from then this
solution is workable. You probably want one so that your organization
can configure things like the enforcer plugin to make sure all your
projects follow the same rules. But if you can't do that then this
solution doesn't
If I can get some time I might look at it as well. This wouldn't
necessarily be a bad thing if it can tell you all of the errors after
preparing the projects.
Milos Kleint wrote:
The build doesn't fail fast now in some cases. It will prepare all the 20
project's lifecycles, perform dependency
In my world I require a reproduceable build. Typically, that means a
specific release would have to be built using a specific version of
Maven. Any attempt to build it at a later time would need to still use
that release. This isn't just because of default versions of plugins
but because the
Tim O'Brien wrote:
People will use whatever implementation they feel like using. I'd
propose that you start by shipping Maven with two:
1. Classic - the way it works now
2. Reduced XML - the thing that Nicolas proposed
If someone wants to ship an implementation that understands something
I think you are missing my point. I have no problem with allowing a more
compact XML using attributes instead of elements. But the minute you
allow the parser to be pluggable you allow folks to start inventing
their own POM syntax. I would find that situation completely
unacceptable. I don't
Actually, there wasn't a single dependency in that pom. Those were all
managed dependency declarations. I'm not surprised to see something like
that, however it would really be better if it was:
dependencyManagement
dependency groupId=org.apache.maven.archiva
artifactId=bill-of-materials
+1
Ralph
Lukas Theussl wrote:
I'd like to propose giving commit access to Benjamin.
During the last few months, he has provided patches in so many areas
of Maven that I can't list them all here (various plugins, surefire,
doxia,...), including documentation and translations, and he has not
OK. Could someone apply the patch I provided for
http://jira.codehaus.org/browse/MNG-1577 and verify it?
Ralph
Carlos Sanchez wrote:
Is not that we don't want to see that fixed, but we're very busy. A
patch would help to get it solved earlier.
Mike,
I'm in the process of creating unit tests for the patch - which is a
good thing because the patch doesn't seem to be working quite the way it
needs to in all cases. Hopefully I'll have this done in the next couple
of days.
Ralph
Mike Perham wrote:
That's too bad. I think deps at
I'm trying to run mvn test
-Dtest=org.apache.maven.project.MavenProjectTest from maven-project.
When I do I get No tests to run. This happens when I name any test case
in the project, not just that class. Is there something special I need
to do?
Thanks,
Ralph
=MavenProjectTest
The test param isn't a classname with package but a pattern on files,
so org/apache/maven/project/MavenProjectTest should be ok too.
Emmanuel
Ralph Goers a écrit :
I'm trying to run mvn test
-Dtest=org.apache.maven.project.MavenProjectTest from
maven-project. When I do I get
be enhanced to check the value
returned from the System.getProperty and if it isn't empty to use that
instead of the hardcoded string.
Ralph
Brett Porter wrote:
On 20/09/2006, at 2:56 PM, Ralph Goers wrote:
Thanks, that worked. Either I'm dense or some better examples would
help. This syntax
Cocoon is using a CMS to manage the documentation. This allows us to
give access to update the documentation without requiring svn commit
access. It is also a better environment to create documentation. If you
want to do that I'd be happy to bring it up on the Cocoon list.
Ralph
Jason van
John,
I've not looked at the Plexus code, but it reminds me a bit of Avalon.
It seems like what you are trying to achieve should be easily doable
except that I am noticing that all the components.xml files are bound to
their components inside their respective jars. I'm not sure why that is,
Assuming Mike Perham's testing goes OK, I would really like to see my
patch for MNG-1577 in 2.0.5. I cannot move forward with Maven 2 at all
until that issue is resolved.
Ralph
Kenney Westerhof wrote:
Hi,
I've talked to several users in the past period about issues in maven
2.0.4.
It's
Does your organization have a need to tightly control the versions of
the jar dependencies you use? If not than maven-2.04 should work just fine.
Aaron Metzger wrote:
For a new project which intends to whole-heartedly embrace Maven2 and
lots of plugins, what is the community consensus as to
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful. But
I understand what you are driving at. If there was a way to register
named phases with the numbers that would be better.
OTOH, wouldn't it be
Steve Loughran wrote:
Simone Gianni wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would
Steve Loughran wrote:
Ralph Goers wrote:
Steve Loughran wrote:
Simone Gianni wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had
Jason van Zyl wrote:
I just don't see the value in this for Maven users. Carl what value do
you see as a real benefit to Maven users who work on Redhat?
Jason.
My 2 cents.
I primarily use Linux to develop Java. Here are the steps I use when
installing RHEL 4.0 WS.
1. Install OS.
2.
Carl Trieloff wrote:
I don't see that there is a consistent view yet on this. It would be
nice to get to a conclusion on whether the Maven community would like
to work with the downstream distros teams so that we can provide a
consistent and good experience. Is there any more information
Jason van Zyl wrote:
Yah, I don't buy it. I don't know anyone who uses RPMs to do anything
with Java.
Actually, if you'll recall our conversations at ApacheCon I mentioned
something like that. RPMs make no sense because the ClassLoader can't
use them. They also make no sense because the
I'm a little curious. I'm a committer on a few projects and am on the
Cocoon PMC. This is the first time I've every heard of a proposal for
people to automatically lose their commit privileges. Although, I
haven't found any rules anywhere that says you can't do it, it seems a
bit odd to me.
Jason van Zyl wrote:
People get voted on to the PMC by other PMC members. Being a committer
doesn't automatically get you on the PMC in these parts. I'm
personally not for the free-for-all access to everything. I don't
honestly understand why there is any distinction between a committer
Well, if you absolutely positively promise to release 2.0.6 when
MNG-1577 is applied ;-) . Seriously, it has been rather frustrating as
I can't even use Maven 2 without that fix.
Ralph
Jason van Zyl wrote:
Hi,
I want to call a vote for 2.0.5. All the issues that are going to get
done are
I have one issue with this.
Typically, at least in the environment I work in (which uses Maven 1),
the version would be something like 1.0.1 only when that version had
been released. When doing any modifications the version should become
1.0.2-SNAPSHOT until the next release is performed. You
Mark Lundquist wrote:
It's not. Did you read the scenario from my original post? I don't
think SNAPSHOT is even in view here.
Yes, I read it.
Do you think it's currently possible to build two different instances
of a project (e.g. one w/ local modifications and one without) on the
same
Mark Lundquist wrote:
IIUC, SNAPSHOT is concerned w/ the relationship btwn. remote and local
repositories. That's not in view here.
Huh? SNAPSHOT identifies an artifact as not-released. There is no
requirement that it ever be published to a remote repository. In our
environment we have our
Mark Lundquist wrote:
no, of course not... nevertheless, SNAPSHOT is only meaningful in
relation to a remote repository, right?
I don't really understand why you'd say that. It indicates that this is
an unreleased version. Whether it is in your local repository or a
remote repository doesn't
What is this well known problem. I tried upgrading the plugin for maven
1.0.2 from version 1.1.1 of cobertura to 1.3 and have the same problem -
all the reports show 0 coverage.
Ralph
Bob Allison wrote:
Sounds like the well-known Cobertura 2.1 problem. Try explicitly
specifying version 2.0
this problem.
- Original Message - From: Ralph Goers
[EMAIL PROTECTED]
To: Maven Developers List dev@maven.apache.org
Sent: Wednesday, February 07, 2007 9:14 AM
Subject: Re: Lifecycle issues with Cobertura plugin and custom plugin
What is this well known problem. I tried upgrading
to the
plugins-user list at sourceforge (see [1] for links). (Btw, did you
check your maven.compile.debug setting?)
Cheers,
-Lukas
[1] http://maven-plugins.sourceforge.net/maven-cobertura-plugin/
Ralph Goers wrote:
No, we have many Maven 1 based projects. We have wanted to move to
Maven 2
Please let me know where it is too.
Mike Perham wrote:
I was hoping I wouldn't have to remind you with a baseball bat this
time. :-)
We've found two issues with our patch in the two weeks we've been
using Maven with it applied locally. We'll have an updated sandbox
for you to review
Patrick Mike took this over. To be honest, I really don't know what
they are doing. I think they are confused over your desire to have this
be just the way it works in 2.1. That means the override tag won't be
there in 2.1. However, it has to be there in 2.0.x to preserve
compatibility.
Some things seem to be missing. ManagedVersionMap doesn't seem to be
present. I also don't see the change to model.mdo to allow overrides to
be enabled.
Brett Porter wrote:
The recent commits for MNG-1577 seem to have broken the build.
On 11/03/2007, at 3:45 AM, [EMAIL PROTECTED] wrote:
Jason,
Well, I view the behavior of the patch as being correct, but since the
override flag has been removed from the pom it breaks backward
compatibility with previous 2.0 verisons - which is why I added the flag
in the first place.
However, if anyone complains about this it should be
for a .0.x release.
- Brett
Jason van Zyl wrote:
On 14 Jan 07, at 3:26 PM 14 Jan 07, Ralph Goers wrote:
Actually, IMO it does add semantic content.
But I think we've decided the current behavior should not exist. That
we want to replace it because it's wrong. If that's true then I would
Well, obviously I would have no objection. ;-)
+1
Ralph
Jason van Zyl wrote:
Hi,
After working with it a little this week I would like to propose to
make MNG-1577 behavior introduced the default. Builds are completely
and totally unpredictable without this behavior. The behavior in 2.0.5
Question. Has Mike or Patrick updated the documentation yet? I started
to update the wiki a couple of months ago but put it off as I didn't
want the wiki to reflect something that you couldn't yet use. Plus the
behavior changed slightly since then.
If they haven't beaten me to it, I'd be
to it through you or Mike?
On 3/15/07, *Ralph Goers* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Question. Has Mike or Patrick updated the documentation yet? I
started
to update the wiki a couple of months ago but put it off as I didn't
want the wiki to reflect
Brett,
As others have pointed out, most people have gotten around this by
explicitly specifying the dependencies in their pom, even though they
aren't direct dependencies. This change won't affect them. It only
affects folks who let Maven handle transitive dependencies and it will
also
Jason van Zyl wrote:
I will work with Patrick to put the old and new in 2.0.x. If it really
comes down to turning it off by default, which would be an immense
shame, then so be it and people will just have to turn it on. We'll
just devise a very easy way to turn it on like a property in the
Jason van Zyl wrote:
I will also help because we need a spec that people can read to
understand what exactly happens. There is a fundamental level of
confusion as to how snapshots work, how versions work where, and how
you accurately control what versions get pulled in. Ralph, I would
See Below
Brett Porter wrote:
I'm generally in favour now, but there are a couple of things I'd
still like to explore first, please bear with me.
Having had the chance to review the new behaviour, I can't see any
problems with applying it to current builds - I would expect it
extremely rare
Jason van Zyl wrote:
The depMan declarations now channels all transitive dependency to what
the user specifies, but what we still need in the future when ranges
become common place is the conflict resolution mechanism as we've
always thought it would work. Because the overwhelming majority
Jason van Zyl wrote:
Looks like we're all set here too. I'll take care of Ralph's karma.
Thanks, Jason. I look forward to helping out!
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Just curious, but I'm interested in why you want to do this. It drives
me nuts when I get a product such as Jboss and I can't figure out what
version it is using just by looking at the file name. OTOH, I'd be just
as happy to run a command line program that could accurately tell me the
Actually, that depends on who you ask. If you read the FSF site you'd
get the impression it is not. JBoss says it is. What is most important
is that according to what I've seen on Apache legal-discuss the project
can't have direct dependencies on LGPL'd software.
It would make a lot of sense
I did commit it to trunk. It just took me a while to do it as my
maven-artifact was seriously out of date and I was getting compile
errors in maven-project (and I had to go to work for the day) so it took
me a while to verify it.
If you really think this warrants a Jira issue I can create
Maybe that's because I didn't merge? Would merging from 2.0.x to trunk
work correctly? I guess it wouldn't have hurt to try.
Brett Porter wrote:
sorry, I see the trunk commit now - just didn't have the normal
merged from notation. Same question applies for the reasoning :)
On 25/02/2008,
I checked it in before so it is still in SVN. I just have to put that
version back on top.
Where do the release notes go?
Ralph
Brett Porter wrote:
I think this is mostly for Ralph... I wasn't able to find any
documentation for the import scope in the site. I was wondering if you
could add
http://marc.info/?l=turbine-maven-devm=119061621617466w=2
http://marc.info/?l=turbine-maven-devm=119061621501107w=2
These were reverted. I just need to get it back and make some minor updates.
Ralph
Brett Porter wrote:
On 29/02/2008, at 11:22 AM, Ralph Goers wrote:
I checked it in before so
There is a test in maven-project under imports. Is this not sufficient?
Brian E. Fox wrote:
Ralph: can we get some Its for this too? We want to make 2.0.9 final
this week.
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 28, 2008 8:32 PM
I'm having a problem building 2.0.x. I had a working build which I
updated from svn last week. I updated a few minutes ago and it failed. I
did a fresh checkout and tried it again but got the same failure.
Here is the log from the build.
Note: Some input files use unchecked or unsafe
Sure. I can document this. I have already written the code that accounts
for the circularity problem. Instead of getting the stack overflow or
out of memory error it will throw a ProjectBuildingException and
identify both the failing artifact and the parent. However, I have to
retest this
Now it is failing again, albeit differently. I'm getting a
NullPointerException. Here is the tail end of the log.
Building project in /projects/maven2/temp/maven-2.0.x/apache-maven
--
Cleaning
Now I'm wondering how the rest of you actually build maven. I checked
out from the 2.0.9 tag and it failed the same way. So I guess
bootstrap.sh isn't actually used to build Maven for a release?
Ralph Goers wrote:
Now it is failing again, albeit differently. I'm getting a
NullPointerException
Brian E. Fox wrote:
Nope, you can't run the release plugin from the bootstrap...I just use
whatever maven I happen to have installed, usually the snapshot I last
built for testing.
Does this mean it is OK to release 2.0.9 even though bootstrap.sh
doesn't work? Just curious.
Brian E. Fox wrote:
I read about the new import scope in the 2.0.9 release notes. This
looks very promising to me, but I have a questions on the details of
how this works.
I looked in the mailing list history for discussions on this feature,
but couldn't find anything. There is a wiki page, but
Tom Huybrechts wrote:
I read about the new import scope in the 2.0.9 release notes. This
looks very promising to me, but I have a questions on the details of
how this works.
I looked in the mailing list history for discussions on this feature,
but couldn't find anything. There is a wiki page,
I updated the introduction to dependency mechanism page and built the
site locally. I then checked it in. The last time I did this was in
September and I can't for the life of me remember how to publish the
site - I remember logging in to people.apache.org and doing some stuff
over there. I've
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 6:35 PM
To: Maven Developers List
Subject: Re: Documentation for import scope
I updated the introduction to dependency mechanism page and built the
site locally. I then checked it in. The last time I did
The download page still says 2.0.8. Did you intend that?
[EMAIL PROTECTED] wrote:
Author: brianf
Date: Wed Apr 9 21:54:44 2008
New Revision: 646646
URL: http://svn.apache.org/viewvc?rev=646646view=rev
Log:
changes to site for 2.0.9 release
Added:
The mechanism for Artifact version checking should really be pluggable.
It looks like it was originally intended to be (why else would it be
named DefaultArtifactVersion and implement an interface), but the code
just does new DefaultArtifactVersion. I would prefer to have this fixed
before
I did this with Maven 1 and I'm sure it would work with Maven 2, but it
may not be what your want. The way I handled it was to dynamically
construct the pom in a target directory along with the project files and
then invoke the goal (plugin) calls Maven again just for that project.
Richard
The better question is what will it take to get the patches applied? I
took a glance at 3559 and nothing jumped out and bit me. However, I'd
like other feedback, plus I'd be hesitant to apply it without the patch
having a test case included to verify the fix. I don't have the
bandwidth right
My 2 cents. I happen to like Spring. I know Avalon really well which
Plexus has its roots in. That being said, I really don't care which one
is used as long as DI is really used, and that is where the problem is.
Things that should have been wired via configuration aren't (i.e.
Paul Gier wrote:
I would like to bring up a couple of issues related to profile
activation and deactivation. While working on MNG-3545 I noticed some
cases where the current behaviour might be improved.
1. What is the correct behaviour when there is more than one
activeByDefault profile
+1. My first reaction though was the thought, what should -P-profile
do? Is it confusing not to have it if + is supported? Would it be the
same as -P!profile?
Bernhard David wrote:
would it be possible to have -Pprofile work as usual (activate
profile, deactivate defaults) but -P+profile
1 - 100 of 393 matches
Mail list logo
