Hi,

OK, that explains it. If ANY profile is active, the profiles which are 
activeByDefault are not active. Your change enables the doclint-java-8 
profile if the build is running on JDK 8 or later (so always...).

@Achim: The problem is not that the containers are not tested, but that 
they are not built (because of this profile issue).

I see two options:
1. We remove the profiles and have the containers built always (as the 
release profiles). The build time for the containers is anyway rather small 
compared to the other stuff (especially if you run the tests).
2. As starting from pax-web-6.0 the build is running on Java 8, anyway, we 
might set the property as well outside a profile for these branches.

Best regards
Stephan

Am Mittwoch, 22. November 2017 09:33:39 UTC+1 schrieb Grzegorz Grzybek:
>
> Hello, I can answer to:
>
> Why are these profiles there at all? Wouldn't it be easier to remove all 
>> these profiles and build all containers by default?
>>
>
> The problem is with Maven itself. After I introduced:
>
> <profile>
>     <id>doclint-java8-disable</id>
>     <activation>
>         <jdk>[1.8,)</jdk>
>     </activation>
>     <properties>
>         <javadoc.opts>-Xdoclint:none</javadoc.opts>
>     </properties>
> </profile>
>
> Maven stopped taking <activeByDefault> into account for tomcat, jetty and 
> undertow profiles.
>
> The change[1] was related to my general build fixes.
>
> regards
> Grzegorz Grzybek
> ===
> [1]: 
> https://github.com/ops4j/org.ops4j.pax.web/commit/247a1f6b90e4a9d4c2e914672462c38e4349eeed
>
> 2017-11-22 8:52 GMT+01:00 Stephan Siano <stepha...@sap.com <javascript:>>:
>
>> Hi,
>>
>> I have a few (not really related) questions concerning pax-web:
>>
>> 1. There are separate profiles for building tomcat, jetty, and undertow 
>> support. At least when I do the builds locally none of these profiles is 
>> activated by default. The workaround for my local build is to use the 
>> -Prelease parameter. The same issue applies with the CircleCI build created 
>> for pull requsts. It does not build any container support (and fetches it 
>> from nexus, which means that it executes new tests with old 
>> implementations). I have not found a way to enable the release profile for 
>> the CircleCI builds, but this may be because of my lack of understanding 
>> about the CircleCI infrastructure.
>>
>> My question: Why are these profiles there at all? Wouldn't it be easier 
>> to remove all these profiles and build all containers by default?
>>
>> 2. There is one jetty test consistently failing. The test is rather jetty 
>> specific and I am not deep enough in the jetty implementation to fix it (or 
>> event to esimate how important that is), so I created a JIRA bug for it 
>> (PAXWEB-1136). The test error makes all CircleCI jobs fail (for pull 
>> requests) and prevents any SNAPSHOT propagation to nexus. 
>>
>> What would be the best way to proceed? Disable the test (with a reference 
>> to the JIRA bug) to allow proper validation of unrelated pull requests or 
>> keep it in error as a reminder that it should be fixed?
>>
>> Best regards
>> Stephan
>>
>> -- 
>> -- 
>> ------------------
>> OPS4J - http://www.ops4j.org - op...@googlegroups.com <javascript:>
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ops4j+un...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
-- 
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
You received this message because you are subscribed to the Google Groups 
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to