Reactor versus classifiers ...
I've hit a problem with Maven 3.2.5 and the karaf-maven-plugin.
One module builds a Karaf feature with the karaf maven plugin; this produces:
${project.groupId}
rosapi-features
${project.version}
features
xml
runtime
The packaging of this project is 'feature' to use the karaf-maven-plugin.
The second module consumes it, via the dependency above. It also uses
the karaf-maven-plugin with a different packaging to make the karaf
assembly.
When I try to run release:prepare, I fail, because the features.xml
file is not, apparently, resolved correctly from the reactor. Does
anyone here on the Maven side have any suggestions before I try to
dive into the Karaf side? Of course, it works fine when I am _not_
running the release plugin.
[INFO] [WARNING] Error resolving
artifactcom.basistech.ws:rosapi-features:xml:features:0.7.100:Could
not find artifact
com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
Technology Corp. Nexus
(http://nexus.basistech.net:8081/nexus/content/groups/public)
[INFO] shaded.org.eclipse.aether.resolution.ArtifactResolutionException:
Could not find artifact
com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
Technology Corp. Nexus
(http://nexus.basistech.net:8081/nexus/content/groups/public)
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shared Component: Maven Archiver Version 3.0.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Archiver Version 3.0.0. The Maven Archiver is mainly used by plugins to handle packaging. The version numbers referenced in the Since column on this page are the version of the Maven Archiver component - not for any specific plugin. To see which version of Maven Archiver a plugin uses, go to the site for that plugin. Important Notes: * Maven 3.X only * JDK 6 minimum requirement http://maven.apache.org/shared/maven-shared-utils/ You should specify the version in your project's plugin configuration: org.apache.maven.shared maven-archiver 3.0.0 Release Notes - Apache Maven Shared Utils - Version 3.0.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12333673 Improvements: * [MSHARED-380] - Fix Checkstyle reported errors/warnings * [MSHARED-387] - Upgrade plexus-archiver from 2.8.1 to 2.9 * [MSHARED-438] - Use Maven 3.0 Dependencies * [MSHARED-445] - Upgrade maven-shared-utils 3.0.0 * [MSHARED-446] - Upgrade version to 3.0.0-SNAPSHOT * [MSHARED-447] - Use fluido skin 1.4 Enjoy, The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
surefire 2.19 regression?
Hi mvn test -Dtest=com.xxx.yyy.MyTest no longer works it works with 2.18.1 Netbean IDE also not able to run individual test since it uses surefire to run test is it a regression? -Dan
RE: Reactor versus classifiers ...
> Date: Wed, 21 Oct 2015 13:56:39 -0400
> Subject: Reactor versus classifiers ...
> From: bimargul...@gmail.com
> To: users@maven.apache.org
>
> I've hit a problem with Maven 3.2.5 and the karaf-maven-plugin.
>
> One module builds a Karaf feature with the karaf maven plugin; this produces:
>
>
> ${project.groupId}
> rosapi-features
> ${project.version}
> features
> xml
> runtime
>
>
> The packaging of this project is 'feature' to use the karaf-maven-plugin.
>
>
> The second module consumes it, via the dependency above. It also uses
> the karaf-maven-plugin with a different packaging to make the karaf
> assembly.
>
> When I try to run release:prepare, I fail, because the features.xml
> file is not, apparently, resolved correctly from the reactor. Does
> anyone here on the Maven side have any suggestions before I try to
> dive into the Karaf side? Of course, it works fine when I am _not_
> running the release plugin.
>
> [INFO] [WARNING] Error resolving
> artifactcom.basistech.ws:rosapi-features:xml:features:0.7.100:Could
> not find artifact
> com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
> Technology Corp. Nexus
> (http://nexus.basistech.net:8081/nexus/content/groups/public)
> [INFO] shaded.org.eclipse.aether.resolution.ArtifactResolutionException:
> Could not find artifact
> com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
> Technology Corp. Nexus
> (http://nexus.basistech.net:8081/nexus/content/groups/public)
MG>you can add a jaraf feature to feature repository via
MG>feature:addMG>https://karaf.apache.org/manual/latest/users-guide/provisioning.htmlMG>verify
the feature registration has taken placeMG>feature:repo-list
MG>at some point you may want to assemble
MG>https://karaf.apache.org/manual/latest/developers-guide/custom-distribution.htmlMG>where
maven-assembly specifies descriptor
src/main/descriptors/bin.xml in configurationMG>the
assembly bin.xml contains filenames you wish to include in
MG>karaf plugin produces kar assemblies from OSGI buildMG>once kar assembly is
created you can cp to deploy folderMG>then use the
'feature-deployer'https://karaf.apache.org/manual/latest/users-guide/deployers.htmlhttps://karaf.apache.org/manual/latest/users-guide/provisioning.html
Have fun> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
Re: Reactor versus classifiers ...
None of this is relevant to the simple build process of incorporating
a feature in a karaf assembly.
Adding 'install' to the preparationGoals of the release plugin is the
workaround.
On Wed, Oct 21, 2015 at 8:41 PM, Martin Gainty wrote:
>
>
>> Date: Wed, 21 Oct 2015 13:56:39 -0400
>> Subject: Reactor versus classifiers ...
>> From: bimargul...@gmail.com
>> To: users@maven.apache.org
>>
>> I've hit a problem with Maven 3.2.5 and the karaf-maven-plugin.
>>
>> One module builds a Karaf feature with the karaf maven plugin; this produces:
>>
>>
>> ${project.groupId}
>> rosapi-features
>> ${project.version}
>> features
>> xml
>> runtime
>>
>>
>> The packaging of this project is 'feature' to use the karaf-maven-plugin.
>>
>>
>> The second module consumes it, via the dependency above. It also uses
>> the karaf-maven-plugin with a different packaging to make the karaf
>> assembly.
>>
>> When I try to run release:prepare, I fail, because the features.xml
>> file is not, apparently, resolved correctly from the reactor. Does
>> anyone here on the Maven side have any suggestions before I try to
>> dive into the Karaf side? Of course, it works fine when I am _not_
>> running the release plugin.
>>
>> [INFO] [WARNING] Error resolving
>> artifactcom.basistech.ws:rosapi-features:xml:features:0.7.100:Could
>> not find artifact
>> com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
>> Technology Corp. Nexus
>> (http://nexus.basistech.net:8081/nexus/content/groups/public)
>> [INFO] shaded.org.eclipse.aether.resolution.ArtifactResolutionException:
>> Could not find artifact
>> com.basistech.ws:rosapi-features:xml:features:0.7.100 in Basis
>> Technology Corp. Nexus
>> (http://nexus.basistech.net:8081/nexus/content/groups/public)
>
> MG>you can add a jaraf feature to feature repository via
> MG>feature:addMG>https://karaf.apache.org/manual/latest/users-guide/provisioning.htmlMG>verify
> the feature registration has taken placeMG>feature:repo-list
> MG>at some point you may want to assemble
> MG>https://karaf.apache.org/manual/latest/developers-guide/custom-distribution.htmlMG>where
> maven-assembly specifies descriptor
> src/main/descriptors/bin.xml in configurationMG>the
> assembly bin.xml contains filenames you wish to include in
>
> MG>karaf plugin produces kar assemblies from OSGI buildMG>once kar assembly
> is created you can cp to deploy folderMG>then use the
> 'feature-deployer'https://karaf.apache.org/manual/latest/users-guide/deployers.htmlhttps://karaf.apache.org/manual/latest/users-guide/provisioning.html
> Have fun>
> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Proper Project and Module Configuration
I am not quite sure how to ask this to make it simple, but let's say I had a bunch of applications that wanted to share the same version via a Parent POM - should they all be inside the same module? If so, what about the Parent POM, should that be inside the module too? I am thinking about when it comes time to release them, I am having a devil of a time trying to make separate modules (that are inter-dependent on each other's artifacts) release nicely using the same version. What is best practice? It seems like the way we have it setup is totally wrong, and would take a while to explain --- which is why it is probably wrong.
Re: Proper Project and Module Configuration
Typically, you would make each module produce a single artifact (e.g., application). The parent POM can be the multi-module POM used to build all of its modules. Any module can, itself, be an aggregator and parent of its modules so you can nest things in whatever way makes sense... Robert Patrick VP, OPC Development, Oracle Mobile: +1 469 556 9450 Sent from my iPad > On Oct 21, 2015, at 8:25 PM, Scott Klein wrote: > > I am not quite sure how to ask this to make it simple, but let's say I had a > bunch of applications that wanted to share the same version via a Parent POM > - should they all be inside the same module? > > If so, what about the Parent POM, should that be inside the module too? > > I am thinking about when it comes time to release them, I am having a devil > of a time trying to make separate modules (that are inter-dependent on each > other's artifacts) release nicely using the same version. > > What is best practice? > > It seems like the way we have it setup is totally wrong, and would take a > while to explain --- which is why it is probably wrong. > >
Re: Proper Project and Module Configuration
You would want your parent to be in the root directory of a tree with subdirectories,preferably named after your submodules, holding your module poms On Wed, Oct 21, 2015, 8:25 PM Scott Klein wrote: > I am not quite sure how to ask this to make it simple, but let's say I had > a bunch of applications that wanted to share the same version via a Parent > POM - should they all be inside the same module? > > If so, what about the Parent POM, should that be inside the module too? > > I am thinking about when it comes time to release them, I am having a > devil of a time trying to make separate modules (that are inter-dependent > on each other's artifacts) release nicely using the same version. > > What is best practice? > > It seems like the way we have it setup is totally wrong, and would take a > while to explain --- which is why it is probably wrong. > > >
Maven Checkstyle Plugin - IllegalType rule configuration not working
Hello all,
I’m using Maven-Checkstyle-Plugin version 2.17 (with Checkstyle 6.11.2).
I’m trying to get the Checkstyle plugin to break the build whenever one of
the pre-JDK8 date/time types are used in the *public API* (but not the
internal state) of a class. This implies that applications can use properly
working date/time classes while making ORM frameworks adhere to the JPA
standard - which works properly with pre-JDK8 date/time types. The pattern
becomes:
*Example:*
@NotNull
@Basic(optional = false)
@Column(nullable = false)
@Temporal(value = TemporalType.TIMESTAMP)
private Calendar startTime;
… with the corresponding getter …
/**
* @return The start time of the Activity.
*/
public ZonedDateTime getStartTime() {
return ZonedDateTime.ofInstant(startTime.toInstant(),
startTime.getTimeZone().toZoneId());
}
*Checkstyle configuration:*
Rule configuration should be simple enough, according to the documentation.
Simply is the property ”tokens” to set the illegal types to be used as
PARAMETER_DEF and METHOD_DEF only (and hence not VARIABLE_DEF), and the
private Calendar startTime should pass validation. The configuration is
shown below.
However, when running the check, maven-checkstyle-plugin breaks the build
on the startTime variable (which should correspond to a VARIABLE_DEF …
which is not present in the configuration). What am I missing here? The
Checkstyle plugin seems to ignore the ”tokens” property:
[ERROR]
src/main/java/se/mithlond/services/organisation/model/activity/Activity.java:[155,17]
(coding) IllegalType: Declaring *variables,* return values or parameters of
type 'Calendar' is not allowed.
--
--
+==+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+
