Hi Andreas,

> Now, one might argue that the m-jarsigner-p needs to become smarter
> and aware of Maven's offline mode, but that would require it to deal
> with special cases, like localhost URLs being reachable even in
> offline mode

I would argue that, yeah. And that it should ignore such special cases, and
just do nothing (or fail the build maybe) when in offline mode. Though
special casing "file://" would be trivial to do. Maybe worth filing a JIRA
issue for it? Doesn't look like there are any issues relating to this in
the system yet [1].

> being able to activate a profile on ${settings.offline} doesn't
> preclude that as, AFAIK, that magic property can only be set before
> Maven "starts doing things like resolving parent POMs", i.e., on the
> command line or in the settings.xml itself.

Sure, that makes sense to me too. After all, settings.xml is always there
on the local machine and intuitively, it seems like it would be easy to add
support for profile activation based on settings. But I am naive there!

Regards,
Curtis

[1]
https://jira.codehaus.org/issues/?jql=project%20%3D%20MJARSIGNER%20AND%20text%20~%20offline

On Thu, Feb 5, 2015 at 3:05 PM, Andreas Sewe <
s...@st.informatik.tu-darmstadt.de> wrote:

> Hi Curtis,
>
> many thanks for your detailed reply.
>
> You wrote:
> >> Is this by design, i.e., is ${settings.offline} different from,
> >> say, a property ${my.offline} that I activate with -D?
> >
> > For better or for worse, Maven profiles cannot be activated based on
> Maven
> > properties, only based on Java system properties and/or environment
> > variables. That is, anything you pass in via -Dfoo.bar can be used for
> > activation, but all those properties you put in the <properties> section
> of
> > your POM, or in settings.xml, cannot trigger profiles. The Maven offline
> > property is one of the latter, not the former.
>
> Yes, but settings.offline is arguably different from things in a
> properties section because it is, as you point out below, a top-level
> element in settings.xml (/settings/offline rather than
> /settings/properties/offline). As such, it at least seems plausible that
> settings.* properties act the same as env.* properties.
>
> >> does there exist a different way to achieve the same thing,
> >> i.e., activate a profile when -offline?
> >
> > After 30+ minutes of thinking about this and trying things and grepping
> > Maven source code, I do not think what you want to do is obviously
> possible.
> >
> > Pragmatically, I thought maybe you could enable offline mode using a
> > profile in your settings.xml activated on an environment variable, but
> you
> > cannot toggle the offline setting in such a profile, because <offline>
> is a
> > toplevel element (i.e., not declared beneath <properties>).
>
> Maybe I phrased my original question not clearly enough: I don't want to
> *enable* offline mode. I simply want to configure some plugin (the
> maven-jarsigner-plugin's <tsa> configuration option, to be precise) iff
> I am running Maven with -offline. The problem is that, with a Time
> Stamping Authority URL configured, the m-jarsigner-p tries to connect to
> the TSA, even if -offline, which cannot succeed and causes the build to
> fail.
>
> Now, one might argue that the m-jarsigner-p needs to become smarter and
> aware of Maven's offline mode, but that would require it to deal with
> special cases, like localhost URLs being reachable even in offline mode,
> etc. IMHO, it is thus far simpler to just be able to configure an
> "offline" profile that adapts your plugin configurations if -offline is
> used.
>
> > The greater design issue is that Maven needs to know whether it is
> offline
> > mode before it starts doing things like resolving parent POMs. But that
> > resolution is necessary in order to fully interpolate the POM and hence
> > know which profiles are activated.
>
> I get that. But being able to activate a profile on ${settings.offline}
> doesn't preclude that as, AFAIK, that magic property can only be set
> before Maven "starts doing things like resolving parent POMs", i.e., on
> the command line or in the settings.xml itself.
>
> Do you agree? If so, do you think this might be worth an enhancement
> request? (I think the m-jarsigner-p use case is pretty compelling, but
> then again that's the problem I am facing at work right now, so I may be
> a bit biased. ;-)
>
> Best wishes,
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to