Michal Maczka wrote:
<snip>
> As I understand (correct me if I am wrong):
> If you use <jar>NAME-OF_YOUR_FILE</jar> file specified by this tag will be
> searched in location jars/NAME-OF_YOUR_FILE
> while ejb plugin installs them (correctly) in folder 'ejbs'.
Nope. Look at the org.apache.maven.project.Dependency, line #241
If you use <jar> it will be used as the file name, but it does not
affect which diretory the file is searched in. Directory is determined
in org.apache.maven.repository.AbstractArtifact lines #127, #135 & #143
It depends on the <type> of the dependency.
Going back to Dependency lines #249 & #254 you'll see the dependency
<type> is used as the file extension when <jar> tag is not present.
This is what causes your trouble in the first place.
Here's a sketch of solution:
Appending extension to the artifact's name should be moved from the
Dependency class to the Artifact implementations. There should be a
getExtension() method in the Artifact interface. AbstractArtifact
implementation should return getType(); to maintain current behaviour.
An EjbArtifact class should be derived from GenericArtifact that
overrides the forementioned method to return "jar";
DefaultArtifactFactory should return instances of EjbArtifactFactory
whenever an artifact of type "ejb" is created.
> [Bit off Topic] I think also that <jar> should be replaced in favor of other
> tag e.g. <file> to make it more generic.
> I know that jars are the most frequently used artifacts, but...
I second that! Changes to POM schema are no easy bussiness however. If
there is commiter agreement on the issue <file> tag could be added, and
<jar> deprecated over time.
<snip>
> I think than in dependencies mechanism at least two things can be improved:
>
> 1. Type handling
>
> The value of <type> tag can be used for resolving some extra information
> about artifacts.
> E.g. config file like:
>
>
> <type-definitions>
> <type-def>
> <name>ejb-jar<type>
> <ext>jar<ext>
> <dir>ejbs<dir>
> <description>ejb-jar module of J2EE application</description>
> </type-def>
> <type-def>
> <name>war<type>
> <ext>war<ext>
> <dir>wars<dir>
> <description>Web Application Archive (WAR)module of J2EE
> application</description>
> </type-def>
> <type-def>
> <name>dtd<type>
> ...
> <type-definitions>
>
>
> can be used.
I see what you mean. I have a similar idea that chimes with the current
way of handling things in maven. The following interface could be created:
public interface ArtifactFactory
{
/**
* @return an artifact instance of <code>null</code> if type not
* supported.
*/
public Artifact createArtifact(String type);
public void registerFactory(ArtifactFactory factory);
}
the DefaultArtifactFactory would be changed to have a static
getInstance() method, and non-static createArtifact method.
This scheme of things would allow plugins (like EJB) plugin register
artifact factories during initialization time. An Artifact instnace
handles the details of directory/file naming so it provides most of
the funcitonality you request above.
> 2. Multiple dependencies
>
> It will be nice if one can set dependency for group of files. Then it will
> be possible to set dependencies for entire frameworks like struts-1.1b3
> without a need of making it file by file.
You are getting close to the dependency metadata subject that has caused
some heated discussion lately... I'm not juping into it ATM :)
R.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
