Asked  7 Months ago    Answers:  5   Viewed   97 times

This is a snippet of my pom file.

....
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>2.4</version>                        
                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            ......
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
...

I use it successfully with the command

mvn install

But, when I try to enclose it into the "pluginManagement" tag, the maven-dependency-plugin stops working when I launch the install goal. Why does the "pluginManagement" tag change the build behavior? Or should I use another goal or option?

 Answers

92

You still need to add

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
    </plugin>
</plugins>

in your build, because pluginManagement is only a way to share the same plugin configuration across all your project modules.

From Maven documentation:

pluginManagement: is an element that is seen along side plugins. Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.

Tuesday, June 1, 2021
 
PeanutsMcgee
answered 7 Months ago
43

I don't know if this is the answer or not but it might lead you in the right direction...

The command install:install is actually a goal on the maven-install-plugin. This is different than the install maven lifecycle phase.

Maven lifecycle phases are steps in a build which certain plugins can bind themselves to. Many different goals from different plugins may execute when you invoke a single lifecycle phase.

What this boils down to is the command...

mvn clean install

is different from...

mvn clean install:install

The former will run all goals in every cycle leading up to and including the install (like compile, package, test, etc.). The latter will not even compile or package your code, it will just run that one goal. This kinda makes sense, looking at the exception; it talks about:

StarTeamCollisionUtil: The packaging for this project did not assign a file to the build artifact

Try the former and your error might just go away!

Saturday, June 12, 2021
 
juanrpozo
answered 6 Months ago
40

This is called the placement new operator. It allows you to supply the memory the data will be allocated in without having the new operator allocate it. For example:

Foo * f = new Foo();

The above will allocate memory for you.

void * fm = malloc(sizeof(Foo));
Foo *f = new (fm) Foo(); 

The above will use the memory allocated by the call to malloc. new will not allocate any more. You are not, however, limited to classes. You can use a placement new operator for any type you would allocate with a call to new.

A 'gotcha' for placement new is that you should not release the memory allocated by a call to the placement new operator using the delete keyword. You will destroy the object by calling the destructor directly.

f->~Foo();

After the destructor is manually called, the memory can then be freed as expected.

free(fm);
Sunday, June 13, 2021
 
Novalirium
answered 6 Months ago
56

Welcome to Stack Overflow :).

You are on the right way. Your real problem is using a zip.

The following configuration is ok and work great for me. It's an old one (2 years ago), and I'm not sure that match the best practices. But I Know that's working.

This allow me to share some resources between projects, especially for unit tests.

Zip Project :

pom.xml

<groupId>com.mycompany</groupId>
<artifactId>cfg_dev</artifactId>
<version>1.1.0</version>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <executions>
                <execution>
                    <id>cfg-main-resources</id>
                    <goals>
                        <goal>single</goal>
                    </goals>
                    <phase>package</phase>
                    <configuration>
                        <descriptors>
                            <descriptor>/src/main/assembly/resources.xml</descriptor>
                        </descriptors>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Assembly descriptor : It will produce this artifact : cfg_dev-1.1.0-resources.zip Please, note that

  1. this is a zip archive
  2. the "classifier" is resources (like assembly name)

    resources zip false src/main/resources

Main Project :

pom.xml

Please, note that

  1. this depends on a zip archive
  2. the dependency "classifier" is resources (like previous assembly name)

    <!-- Unit test dependency -->
    <dependency>
        <groupId>com.mycompany</groupId>
        <artifactId>cfg_dev</artifactId>
        <version>${project.version}</version>
        <classifier>resources</classifier>
        <type>zip</type>
        <scope>test</scope>
    </dependency>
    
      ....
    
    <build>
      <testResources>
        <!-- Ressources habituelles  -->
        <testResource>
            <directory>src/test/resources</directory>
            <filtering>true</filtering>
        </testResource>
        <!-- Unzipped resources from cfg_dev  -->
        <testResource>
            <directory>${project.build.directory}/test-resources</directory>
            <filtering>true</filtering>
        </testResource>
    </testResources>
    
    <plugins>
    
        <!-- Unzip shared resources -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <executions>
                <execution>
                    <id>unpack-cfg-test-resources</id>
                    <goals>
                        <goal>unpack-dependencies</goal>
                    </goals>
                    <phase>generate-test-resources</phase>
                    <configuration>
                        <outputDirectory>${project.build.directory}/test-resources</outputDirectory>
                        <includeArtifactIds>cfg_dev</includeArtifactIds>
                        <includeGroupIds>${project.groupId}</includeGroupIds>
                        <excludeTransitive>true</excludeTransitive>
                        <excludeTypes>pom</excludeTypes>
                        <scope>test</scope>
                    </configuration>
                </execution>
            </executions>
        </plugin>
      </plugins>
    

I hope this is clear and that will help you :)

Thursday, June 17, 2021
 
subroutines
answered 6 Months ago
87

In Rust, when you have an operation that may either return a T or fail, you will have a value of type Result<T,E> or Option<T> (E will be the error condition in case of an interesting error).

The function unwrap(self) -> T will give you the embedded T if there is one. If instead there is not a T but an E or None then it will panic.

It is best used when you are positively sure that you don't have an error. If that is not the case usually it is better either pattern-match the error or use the try! macro ? operator to forward the error.

In your example, the call to read_dir() returns a io::Result<ReadDir> because opening the directory might fail. And iterating the opened directory returns multiple values of type io::Result<DirEntry> because reading the directory might also fail.

With try! ? it would be something like this:

fn try_main() -> std::io::Result<()> {
    let entries = std::fs::read_dir("/home/user")?;

    for entry in entries {
        println!("Name: {}", entry?.path().display());

    }
    Ok(())
}

fn main() {
    let res = try_main();

    if let Err(e) = res {
        println!("Error: {}", e);
    }
}

Look how every error case is checked.

(Updated to use ? instead of try!(). The macro still works, but the ? is preferred for new code).

Tuesday, July 27, 2021
 
VostanAzatyan
answered 5 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :  
Share