On Tue, Feb 15, 2011 at 5:58 AM, Adelita Padilla <[email protected]> wrote: > For the possible fix for this issue, I'd agree with Terence's suggestion that > we have an additional NPANDAY profile set in the settings.xml. A property is > set in the profile that will contain the path to where npanday-settings.xml > will be generated. NPanday will check first if that certain profile is not > null, then check if the property is not null also. The path specified in the > property will be the path where NPanday will generate the > npanday-settings.xml file. If no profile/property is set, NPanday will > generate npanday-settings.xml in .m2 folder.
Here's the issue: https://issues.apache.org/jira/browse/NPANDAY-361 Adding a(nother) profile to settings.xml sounds error prone. I'd prefer to have it match the behavior of Maven as closely as possible, which I think means using a command line switch. How about just looking for that switch and assuming that settings.xml and npanday-settings.xml are in the same place? Is there any reason for the NPanday settings to need to live in a different place than the regular settings? If so, then I suppose a property is the way to go. But I would just expect it to be set on the command line. Because NPanday is the 'second' settings file, it will probably be possible to set the property in settings.xml and it will be there by the time NPanday wants it. I don't think this should require a 'special' profile id. Keep it simple. :) Comment from the peanut gallery: can you describe the problem you're trying to solve when you propose a solution? For someone just scanning the mailing list, this doesn't make much sense out of context. But if you give more info you might get someone interested enough to go read the full history (include a link to the issue tracker?) and maybe even get involved to help. At a minimum you'll insert some information in the casual observer's brain about How Stuff Works. -- Wendy
