Re: [RANT] This Maven thing is killing us....
Brett Porter wrote: > > The first thing I'd suggest is for those having problems to try another > mirror. I know requiring everyone to do that is a pain and not a long > term solution, but I'd like to see how much that reduces the problem. > I'm not sure if the following problem has already been mentioned in this thread as somehow my mail client messed up :( We experience problems like the build is working on one machine while not on another one. The reason for this is changing poms on the public repository! M2 does not recognize when a pom is changed on the repository, so once you have a pom for a dependency it's never updated. If now someone builds before the update he has the old version while someone who builds after the update for the first time, gets the new version. And this is exactly the reason why on some machines our build works (they have the new version of a dependency which brings in other transitive dependencies). It took us some time to recognize this as one of the main problems. Obviously, a pom in a public repository should never change, but as there are faulty poms out there, these need to be fixed. So its very likely that this will still happen in the future. So it would be good if m2 could detect changes in the pom and then update the local version. This would at least solve most of our problems. I'm still thinking that adding a switch "turn off transitive dependency handling" would be a nice think as then you really control what you get without adding excludes all over the place. And it seems that m2 is trying to get poms for snapshots even in offline mode (haven't checked if this is filed as a bug already) and more important it downloads snapshot versions from the repository although a newer version of the snapshot is in the local repository. And the interesting thing is, that although a version has been downloaded, the local one is later on used. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Meta information about dependencies in a pom?
Hi, in Apache Sling we have the need to add additional information to a dependency in a pom, basically it's just an xml attribute, like: Now, with a little bit of hacking we could get this working in our plugin be parsing or converting the pom xml file ourselves (we don't need pom inheritance or transitive handling of this additional information) The question now is, what do you think about it? Is there something planned in that direction? If we would do it, do you think that we might get into trouble with future versions of maven? Regards Carsten -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
Maybe a little bit more information :) We need this information just for the build of the project containing this information. It's read by a custom plugin. So even if the information would not end up in the maven repository, we're fine. Carsten 2011/11/7 Carsten Ziegeler : > Hi, > > in Apache Sling we have the need to add additional information to a > dependency in a pom, basically it's just an xml attribute, like: > > > > Now, with a little bit of hacking we could get this working in our > plugin be parsing or converting the pom xml file ourselves (we don't > need pom inheritance or transitive handling of this additional > information) > > The question now is, what do you think about it? Is there something > planned in that direction? If we would do it, do you think that we > might get into trouble with future versions of maven? > > Regards > Carsten > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
Yes, we were using that approach for years now and it turned out to be too error prone as you have to keep the plugin configuration and the dependency list in sync. It doesn't sound like a hard task first, but in our case it caused trouble many times. That's why we would like to have a single point of information. Regards Carsten 2011/11/7 Brett Porter : > The typical pattern used for this is an artefact filter applied to the > configuration of the plugin, rather than information on the dependencies > (like what the dependency plugin goals use). That was a feature of Maven 1 > that we rejected upfront. > > In my experience, it's actually less verbose since you typically include or > exclude just a handful, or can use wildcards, rather than having to put a > property of each dependency. > > - Brett > > On 07/11/2011, at 11:55 AM, Carsten Ziegeler wrote: > >> Maybe a little bit more information :) We need this information just >> for the build of the project containing this information. It's read by >> a custom plugin. So even if the information would not end up in the >> maven repository, we're fine. >> >> Carsten >> >> 2011/11/7 Carsten Ziegeler : >>> Hi, >>> >>> in Apache Sling we have the need to add additional information to a >>> dependency in a pom, basically it's just an xml attribute, like: >>> >>> >>> >>> Now, with a little bit of hacking we could get this working in our >>> plugin be parsing or converting the pom xml file ourselves (we don't >>> need pom inheritance or transitive handling of this additional >>> information) >>> >>> The question now is, what do you think about it? Is there something >>> planned in that direction? If we would do it, do you think that we >>> might get into trouble with future versions of maven? >>> >>> Regards >>> Carsten >>> >>> >>> -- >>> Carsten Ziegeler >>> cziege...@apache.org >>> >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
2011/11/8 Brett Porter : > > On 08/11/2011, at 8:15 AM, Carsten Ziegeler wrote: > >> Yes, we were using that approach for years now and it turned out to be >> too error prone as you have to keep the plugin configuration and the >> dependency list in sync. It doesn't sound like a hard task first, but >> in our case it caused trouble many times. That's why we would like to >> have a single point of information. > > So, wildcards or excludes lists don't help with the sync task? There's no > convention that can be applied (e.g. all dependencies of a certain type, or > the same group ID as the project)? No, unfortunately not - we have a large list of dependencies with different group ids, all having the same type, so while some share the same group id, in the end we have to list each and every artidact id. > > How would you handle transitive dependencies? We don't consider transitive dependencies, so we just include stuff which is really listed in this pom. In the end this is the application assembly which builds the final distribution based on modules. So we list all the modules as direct dependencies to avoid any surprises through transitive dependencies. And we just need additional information on a per module base. This info must also be defined outside of the module, so we can't just include it in the module artifact as the info might vary from app to app and third party modules are involved. Regards Carsten > > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
2011/11/8 David Jencks : > I've run into this problem in 3 or 4 situations and the only practical > solution is to individually list the dependencies with the extra info in the > plugin configurations. I don't really understand the mindset that only the > information needed for some bits of well-known maven can be associated with > dependencies, and all other uses should just duplicate large swathes of maven > configuration to be able to add a couple bits of info per dependency. My > impression is that aether takes a more inclusive view of dependency > properties. So is this something we could implement in Maven (easily)? Carsten > > thanks > david jencks > > On Nov 8, 2011, at 9:00 AM, Brett Porter wrote: > >> >> On 08/11/2011, at 8:15 AM, Carsten Ziegeler wrote: >> >>> Yes, we were using that approach for years now and it turned out to be >>> too error prone as you have to keep the plugin configuration and the >>> dependency list in sync. It doesn't sound like a hard task first, but >>> in our case it caused trouble many times. That's why we would like to >>> have a single point of information. >> >> So, wildcards or excludes lists don't help with the sync task? There's no >> convention that can be applied (e.g. all dependencies of a certain type, or >> the same group ID as the project)? >> >> How would you handle transitive dependencies? >> >> - Brett >> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
2011/11/8 Guo Du : >> too error prone as you have to keep the plugin configuration and the >> dependency list in sync. It doesn't sound like a hard task first, but > What about only configure the dependency list with additional field as > plugin configuration such as: > > > > foo > bar > x.y.z > 1 > > > > > Yes, that's basically a variant of what we came up with, but in this case the dependencies are not considered when maven is calculating a build order for a multi project build, so you end up with a "wrong" order when you are using snapshot dependencies. We had cases where the snapshot dep was built after the assembly causing an old snapshop to end up in the application. And other plugins like the versions plugin don't see this either. But today we learned about the AbstractMavenLifecycleParticipant which hopefully allows us to use above configuration without the above problems. Regards Carsten > -Guo > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Carsten Ziegeler cziege...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
Thanks everyone for the help, Justin has implemented the lifecycle
participant and it seems to solve our problems pretty well.
Regards
Carsten
2011/11/9 Jason van Zyl :
> Yes that's why I said to pull them out. You won't be successful in using
> JSR330. It only works in Tesla, most of which will be integrated back into
> Maven. Just haven't had time to post to the dev list yet. JSR330 and
> @Injectable SLF4J loggers are but a few of a things possible with code that
> exists the Tesla repo.
>
> But it would be easy enough to build that out as a helper where someone just
> needs to define the source of their GAs they want to contribute and let the
> helper take care of the rest.
>
> On Nov 9, 2011, at 7:57 AM, Jesse Glick wrote:
>
>> On 11/09/2011 12:00 AM, Jason van Zyl wrote:
>>>> today we learned about the AbstractMavenLifecycleParticipant
>>>
>>> Here's an example of how it works for matching the dependencies specified
>>> from a 3rd party source to the reactor.
>>> [...]
>>> It's using JSR330, but you can pull those out and use Plexus annotations if
>>> you need it to work in the short term.
>>
>> A standalone example I just got to work: create a jar-packaging project with
>>
>> @Component(role=AbstractMavenLifecycleParticipant.class)
>> public class WhateverNameYouLike extends AbstractMavenLifecycleParticipant {
>> @Requirement private Logger log;
>> @Override public void afterProjectsRead(MavenSession session) throws
>> MavenExecutionException {
>> for (MavenProject p : session.getProjects()) {
>> log.info("tweaking " + p);
>> Dependency d = new Dependency();
>> d.setGroupId("org.apache.commons");
>> d.setArtifactId("commons-io");
>> d.setVersion("1.3.2");
>> p.getDependencies().add(d);
>> }
>> }
>> }
>>
>> built with
>>
>>
>>
>>
>> org.codehaus.plexus
>> plexus-component-metadata
>> 1.5.5
>>
>>
>>
>> generate-metadata
>>
>> generate-metadata
>>
>>
>>
>>
>>
>>
>>
>> org.apache.maven
>> maven-core
>> 3.0.3
>>
>>
>>
>> Now create a quickstart project and edit the main method to say:
>>
>> System.out.println(org.apache.commons.io.EndianUtils.swapInteger(1));
>>
>> Once you tell it
>>
>>
>>
>>
>> ...coordinates as for first project...
>>
>>
>>
>>
>> then it will compile (under 3.0.3) despite not itself declaring a dep on
>> commons-io.
>>
>> BTW I was not successful in using @javax.inject.Singleton in place of
>> @Component.
>>
>>
>> -----
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> -
>
> What matters is not ideas, but the people who have them. Good people can fix
> bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
>
>
--
Carsten Ziegeler
cziege...@apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[M2] Bug in war plugin?
I'm trying to find some strange behaviour with the packaging of the war
plugin and came across this code in the WarMojo:
public void copyResources( ... ) {
if ( !sourceDirectory.equals( webappDirectory ) ) {
...
if ( warSourceDirectory.exists() ) {
...
FileUtils.copyFile(new File( sourceDirectory, ... );
}
Now from what I see here, I think the copyFile operation should work
on the warSourceDirectory and not on the sourceDirectory. WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Bug in war plugin?
Brett Porter schrieb: > It's a bit confusing - warSourceDirectory actually is sourceDirectory > (its passed in as a parameter). Given that the copyResources method > isn't static and only used once, it probably would be better to remove > the first two parameters and use the fields passed in instead. > Ah, yes, now I see it - sorry for the noise. Thanks Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Proposal for filtering of resources
In my opinion the current configuration of resources wrt filtering is a
little bit too complicated and not as user friendly as it could be :)
I think the most natural way is to configure the filters directly on the
resources. This allows to easily configure different resource sets with
different filtering behaviour:
src/resources
**/*.xml
**/description.xml
true
myfilters.properties
src/resources
**/description.xml
true
descfilter.properties
src/resources
**/*.xml
WDYT?
Attached is a patch that should provide this feature - but I don't have
tested it yet and I'm not sure if the properties file is resolved in the
correct location. But it would be a start :) (At least it compiles and
the resource plugin still works the way it is today.)
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Index:
D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java
===
---
D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java
(revision 239437)
+++
D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java
(working copy)
@@ -97,7 +97,7 @@
public void execute()
throws MojoExecutionException
{
-initializeFiltering();
+filterProperties = initializeFiltering(filtering,
filterPropertiesFile);
copyResources( resources, outputDirectory );
}
@@ -110,7 +110,8 @@
{
Map.Entry entry = (Map.Entry) i.next();
File source = (File) entry.getKey();
-String destination = (String) entry.getValue();
+CopyDescription description =
(CopyDescription)entry.getValue();
+String destination = description.destination;
File destinationFile = new File( outputDirectory, destination
);
@@ -119,7 +120,7 @@
destinationFile.getParentFile().mkdirs();
}
-copyFile( source, destinationFile );
+copyFile( source, destinationFile, description );
}
}
catch ( Exception e )
@@ -165,6 +166,8 @@
scanner.scan();
+ResourceFilter filter = new ResourceFilter();
+filter.resource = resource;
List includedFiles = Arrays.asList( scanner.getIncludedFiles() );
for ( Iterator j = includedFiles.iterator(); j.hasNext(); )
{
@@ -177,48 +180,68 @@
entryName = targetPath + "/" + name;
}
-resourceEntries.put( new File( resource.getDirectory(), name
), entryName );
+resourceEntries.put( new File( resource.getDirectory(), name
), new CopyDescription(entryName, filter) );
}
}
return resourceEntries;
}
-private void initializeFiltering()
+private Properties initializeFiltering(boolean doFiltering, File
propertiesFile)
throws MojoExecutionException
{
-if ( filtering )
+if ( doFiltering )
{
try
{
-filterProperties = PropertyUtils.loadPropertyFile(
filterPropertiesFile, true, true );
+return PropertyUtils.loadPropertyFile( propertiesFile, true,
true );
}
catch ( IOException e )
{
throw new MojoExecutionException( "Error loading property file
'" + filterPropertiesFile + "'", e );
}
}
+return null;
}
-private void copyFile( File from, File to )
-throws IOException
+private void copyFile( File from, File to, CopyDescription desc )
+throws IOException, MojoExecutionException
{
-if ( !filtering )
+boolean doFiltering = filtering || desc.filter.resource.isFiltering();
+if ( !doFiltering )
{
FileUtils.copyFile( from, to );
}
else
{
+// first initialize properties for this resource
+if ( desc.filter.properties == null )
+{
+if ( filterPropertiesFile != null && filterProperties == null )
+{
+filterProperties = initializeFiltering( true,
filterPropertiesFile );
+}
+if ( desc.filter.resource.getFilterPropertiesFile() != null )
+{
+Properties resourceProps = initializeFiltering( true, new
File(desc.filter.resource.getFilterPropertiesFile()) );
+resourceProps.putAll(filterProperties
Re: [M2] Proposal for filtering of resources
Brett Porter wrote: > I think this is reasonable, but I'd like to allow multiple sources > (properties, and multiple files). The existence of the filtering element > can be used to trigger it. > > > > value > > > foo.properties > bar.properties > > > > Dowside is that for a single file it is quite verbose. > Yeah, I thought of this, too and I think it makes absolutely sense. So, +1 :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
Kenney Westerhof wrote: > On Wed, 24 Aug 2005, Brett Porter wrote: > >>I think this is reasonable, but I'd like to allow multiple sources >>(properties, and multiple files). The existence of the filtering element >>can be used to trigger it. > > > I don't think it's a good idea to specify the filter files at the > resource level (assuming the below is a child element of > ). Yes, the filtering is a child of the resource. > Specifying tokens however is a good idea. Hmm, actually, I don't see a real difference between specifying tokens directly or "externalizing" them into a properties file. Why do you think that tokens are a good idea while files not? > > I think you should be able to use different filter properties files using > profiles. The resources plugin can check for the presence of all tokens > and bail if some are missing. So: > > > > > tokenname > anothertokenname > > > > > > Specifying the filter files themselves above is only nice if you use > the same token values in different resource files. However, that's not > the most common usecase for using filters: it's for building for different > environments. According to the m2 philosphy you should have different > projects, but it's not possible to filter resources from another project > (unless you use relative paths to resource dirs). So having profiles > with different filter files should solve this (that's what profiles > are for anyway). > Hmm, I agree with the profiles handling, but I think there are use cases where you want to use different property files for a single profile. As I said, using tokens directly in the pom or putting them in a properties file is the same thing, it's just a different location. Therefore I think it makes sense to directly specify property files for the resources in addition to possible tokens. But I don't insists on this, for now I'm happy if I can specify tokens for the filtering. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Compilation problems with latest from SVN
After updating from alpha-3 to the latest from SVN I can't compile Cocoon anymore. I think the problem is related to classloading or handling of classes. As one dependency we have the xml-apis-1.3.02 implementing DOM level 3 interfaces. Although we have declared this dependency in the POM and the jar is downloaded, the DOM level 3 classes are not found. So I guess that classes inside the org.w3c.dom package (and others) comming from the dependencies are ignored and the system classes are used instead. (But this is just a guess). Any idea how to solve this? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
Kenney Westerhof wrote: > On Wed, 24 Aug 2005, Carsten Ziegeler wrote: > > > The difference is that you only define the _tokens_ in the pom, not their > values. This indicates which tokens are used by the resource files. Ah, sorry, I didn't notice this detail in your previous post. Ok, now I get it. > > Specifying both key and value pairs in the pom doesn't allow for users of > the project to specify their own values without modifying the pom itself. True. > You could specify a 'src/main/conf/config.properties' in the pom, > and supply a sample file 'src/main/conf/config.properties.sample' (or even > in the current dir) that users have copy & edit to fill in their specific > settings (smtp servers, hostname, port, location of tomcat/j2ee containers > etc..) > > That way even in a big team each teammember should configure their > test/build environment using the sample file (if this is needed). > > I used to work on projects using this mechanism (using ant), having > a build-dev.properties, build-live.properties, build-test.properties > for different environments, running and with -Dbuild=dev would load > that set of properties. > > (as you can see, my main concern in specifying properties file is for use > in different environments, not centralizing the token data per se). > Ok, I see now and partially agree :) I think you have two different kinds of property files: one for the project maintenance (or whatever you call this) and one for user settings. The first one is not intended to be changed by a user, it contains important settings for the project at a central place. Now, what do you think of the following: a) the resource plugin by default uses a filters.properties file (if present) - we can of course use a different name/location. b) You can specify additional property files on the resource plugin. If two property files contain the same property, the last one wins (or the first one?) You can specify for each property file if the absence of the file is an error. This allows to simply specify a "property.samples" and the "property" file and it's not an error if the "property" file is missing and the "property" file has precedence over the "property.samples" file. c) The POM gets the filtering tags at the resource element: in this filtering element you can specify which tokens are replaced. In addition we provide a way to say: replace all tokens. This is to make it more user friendly. WDYT? -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
I think I picked up a wrong subject, of course I don't mean that I have problems compiling m2 itself. I have problems while using m2 to compile my own project. Carsten Carsten Ziegeler wrote: > After updating from alpha-3 to the latest from SVN I can't compile > Cocoon anymore. I think the problem is related to classloading or > handling of classes. > As one dependency we have the xml-apis-1.3.02 implementing DOM level 3 > interfaces. Although we have declared this dependency in the POM and the > jar is downloaded, the DOM level 3 classes are not found. So I guess > that classes inside the org.w3c.dom package (and others) comming from > the dependencies are ignored and the system classes are used instead. > (But this is just a guess). > > Any idea how to solve this? > > Carsten > > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Brett Porter schrieb: > This be related to the compiler changes that have been going on. > > Carsten - can you svn up with th elogging I just added and check the > library is passed in? > Sure, I can't at the moment, but I'll try tonight and report back tomorrow. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Carsten Ziegeler wrote: > Brett Porter wrote: > >>This be related to the compiler changes that have been going on. >> >>Carsten - can you svn up with th elogging I just added and check the >>library is passed in? >> > > Sure, I can't at the moment, but I'll try tonight and report back tomorrow. > > Carsten > Attached is the log containing the classpath. Now the problem is, that we depend on xml-apis.1.3.02 - which is the official version of the xml-apis containing DOM level 3 classes. As you can see from the log, xml-apis-2.0.2 is used instead. I guess this comes from the transitive dependencies from some other project. Unfortunately 2.0.2 is a faulty number and it is higer than 1.3.02, so 2.0.2 is preferred over 1.3.02. So, is there any way to turn of transitive dependencies and is there any way to tell that 1.3.02 should always be used? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
(This time with log attached) Carsten Ziegeler wrote: > Brett Porter wrote: > >>This be related to the compiler changes that have been going on. >> >>Carsten - can you svn up with th elogging I just added and check the >>library is passed in? >> > > Sure, I can't at the moment, but I'll try tonight and report back tomorrow. > > Carsten > Attached is the log containing the classpath. Now the problem is, that we depend on xml-apis.1.3.02 - which is the official version of the xml-apis containing DOM level 3 classes. As you can see from the log, xml-apis-2.0.2 is used instead. I guess this comes from the transitive dependencies from some other project. Unfortunately 2.0.2 is a faulty number and it is higer than 1.3.02, so 2.0.2 is preferred over 1.3.02. So, is there any way to turn of transitive dependencies and is there any way to tell that 1.3.02 should always be used? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ [DEBUG] Source directories: [D:\dev\workspace\cocoon-2.2\core\..\src\java] [DEBUG] Classpath: [D:\dev\workspace\cocoon-2.2\core\target\classes D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-instrumented\2.0.0\excalibur-pool-instrumented-2.0.0.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-log_all\1.0.0\knopflerfish-log_all-1.0.0.jar D:\dev\maven-repo\repository\jakarta-bcel\jakarta-bcel\20040329\jakarta-bcel-20040329.jar D:\dev\maven-repo\repository\commons-logging\commons-logging\1.0.4\commons-logging-1.0.4.jar D:\dev\maven-repo\repository\commons-beanutils\commons-beanutils\1.4\commons-beanutils-1.4.jar D:\dev\maven-repo\repository\excalibur-store\excalibur-store\1.0\excalibur-store-1.0.jar D:\dev\maven-repo\repository\rhino\rhino\1.6R1\rhino-1.6R1.jar D:\dev\maven-repo\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar D:\dev\maven-repo\repository\commons-jxpath\commons-jxpath\1.2\commons-jxpath-1.2.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-logcommands\1.0.0\knopflerfish-logcommands-1.0.0.jar D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-api\2.0.0\excalibur-pool-api-2.0.0.jar D:\dev\maven-repo\repository\ant\ant-optional\1.5.1\ant-optional-1.5.1.jar D:\dev\maven-repo\repository\xml-apis\xml-apis\2.0.2\xml-apis-2.0.2.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-framework\1.3.3\knopflerfish-framework-1.3.3.jar D:\dev\maven-repo\repository\excalibur-io\excalibur-io\1.1\excalibur-io-1.1.jar D:\dev\maven-repo\repository\xmlbeans\xmlbeans\1.0.3\xmlbeans-1.0.3.jar D:\dev\maven-repo\repository\regexp\regexp\1.3\regexp-1.3.jar D:\dev\maven-repo\repository\commons-httpclient\commons-httpclient\2.0.2\commons-httpclient-2.0.2.jar D:\dev\maven-repo\repository\xerces\xercesImpl\2.7.1\xercesImpl-2.7.1.jar D:\dev\maven-repo\repository\excalibur-naming\excalibur-naming\1.0\excalibur-naming-1.0.jar D:\dev\maven-repo\repository\excalibur-instrument\excalibur-instrument\1.0\excalibur-instrument-1.0.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework-impl\4.2.0\avalon-framework-impl-4.2.0.jar D:\dev\maven-repo\repository\commons-jci\commons-jci\r159148\commons-jci-r159148.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-http_all\1.1.0\knopflerfish-http_all-1.1.0.jar D:\dev\maven-repo\repository\xml-resolver\xml-resolver\1.1\xml-resolver-1.1.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-cm_api\1.0.0\knopflerfish-cm_api-1.0.0.jar D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-impl\2.0.0\excalibur-pool-impl-2.0.0.jar D:\dev\maven-repo\repository\xalan\xalan\2.7.0\xalan-2.7.0.jar D:\dev\maven-repo\repository\excalibur-xmlutil\excalibur-xmlutil\1.0\excalibur-xmlutil-1.0.jar D:\dev\maven-repo\repository\log4j\log4j\1.2.11\log4j-1.2.11.jar D:\dev\maven-repo\repository\excalibur-sourceresolve\excalibur-sourceresolve\1.1\excalibur-sourceresolve-1.1.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework-api\4.2.0\avalon-framework-api-4.2.0.jar D:\dev\maven-repo\repository\concurrent\concurrent\1.3.4\concurrent-1.3.4.jar D:\dev\maven-repo\repository\junit\junit\3.8.1\junit-3.8.1.jar D:\dev\maven-repo\repository\ant\ant\1.6.5\ant-1.6.5.jar D:\dev\maven-repo\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework\4.1.3\avalon-framework-4.1.3.jar D:\dev\maven-repo\repository\commons-cli\commons-cli\1.0\commons-cli-1.0.jar D:\dev\maven-repo\repository\commons-jexl\commons-jexl\1.0\commons-jexl-1.0.jar D:\dev\maven-repo\repository\logkit\logkit\1.2.2\logkit-1.2.2.jar D:\dev\maven-repo\repository\excalibur-logger\excalibur-logger\1.1\excalibur-logger-1.1.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-consoletty\1.0.0\knopflerfish-consoletty-1.0.0.jar D:\dev\maven-repo\repository
Re: [M2] Proposal for filtering of resources
>From the plan below, I'm able to address a) and b), but currently I don't know how to enhance the POM (Item c)). So if anyone could implement c) I'm willing to provide a patch for the resource plugin. Carsten Carsten Ziegeler wrote: > Now, what do you think of the following: > a) the resource plugin by default uses a filters.properties file (if > present) - we can of course use a different name/location. > > b) You can specify additional property files on the resource plugin. If > two property files contain the same property, the last one wins (or the > first one?) You can specify for each property file if the absence of the > file is an error. This allows to simply specify a "property.samples" and > the "property" file and it's not an error if the "property" file is > missing and the "property" file has precedence over the > "property.samples" file. > > c) The POM gets the filtering tags at the resource element: in this > filtering element you can specify which tokens are replaced. In addition > we provide a way to say: replace all tokens. This is to make it more > user friendly. > > WDYT? -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
Trygve Laugstøl wrote: > On Thu, Aug 25, 2005 at 03:18:45PM +0200, Carsten Ziegeler wrote: > >>From the plan below, I'm able to address a) and b), but currently I >>don't know how to enhance the POM (Item c)). So if anyone could >>implement c) I'm willing to provide a patch for the resource plugin. > > > You can change the POM model in maven-model/maven.mdo > Yes, I know - but I'm not sure how to add a nested structure to it, but perhaps I can figure it out somehow... But before I start working on a patch, I would like to know if there is general interest in it. I don't want to work for the trashcan :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Brett Porter wrote: > That's actually a bug we need to fix. While the resolution technique > might be "latest" instead of "nearest", I think the version in the > current POM should always win. Yes :) > You could actually do this by using > [1.3.02] in the mean time, How do I specify this? [1.3.02] creates a NPE. > or you can add exclusions for those > introducing the other xml-apis (trace that using -X). If you actually > think they are erroneous in the first place, feel free to file a MEV > JIRA issue. > > The xml-apis situation is quite a mess and unfortunately 2.0.2 seems > very prevalent. It would be fantastic if we could get some sanctioned > releases to use instead (or can we use jaxp-1.3?) > I was thinking about using a new name like xml-commons-apis as it is a sub project of the xml-commons project. This would solve the mess but introduce a new name. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
Kenney Westerhof wrote: > Thinking about this, I'm not really sure anymore what the correct solution > would be. We have the following features/demands: I had the same feeling yesterday when I wrote the last proposal :) > > 1) being able to split resources up into two groups: the filtered-on-copy > group and the 'just-copy' group. > > 2) being able to specify different filter properties using profiles > > 3) (?) being able to split filtered resources up into more groups (not > just the one group as said in 1), so each group can have a different filter > property files. > > > 4) being able to specify multiple properties files / having a default file > so users can override. Much like project.properties/build.properties > in maven1. > > 5) Nice to have: defining the tokens in the pom so the plugin > could check which ones are missing and you have an overview of > all the configuration settings used in all the resource files > (the latter being more important). > > More ideas? Comments? > > I think it's best to go back after a while, look at > what you originally _needed_ in the first place, and then fill in the > blanks with solutions. ;) > Hehe, now, actually the more I think about it the more I agree with your list, meaning we don't need 3) and 5) is nice to have but not important. I could imagine that most users would not use 5) anyway and would use the default. I'll start filing a JIRA entry soon with a proposal and as soon as we agree on something there, I will try to implement it. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Brett Porter wrote: > Carsten Ziegeler wrote: > > >>How do I specify this? >>[1.3.02] creates a NPE. >> >> > > Another bug?! It seems so :( I get this stack trace: java.lang.NullPointerException: version was null for xml-apis:xml-apis at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtif act.java:295) at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java: 202) at org.apache.maven.artifact.resolver.DebugResolutionListener.includeArt ifact(DebugResolutionListener.java:56) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent (DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent (DefaultArtifactCollector.java:254) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(D efaultArtifactCollector.java:166) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(D efaultArtifactCollector.java:204) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(D efaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra > > Does [1.3.02,1.3.02] work? > No, you get this message :) (which is ok) I tried [1.3.01,1.3.02] and [1.3.02,1.3.03] all resulting in the same NPE. Do you want me to file a JIRA issue? Carsten [INFO] Main Error: Error in dependency version Root error: Range cannot have identical boundaries: [1.3.02,1.3.02] [INFO] - --- [DEBUG] Trace org.apache.maven.artifact.resolver.ArtifactResolutionException: Error in depende ncy version at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende ncies(DefaultPluginManager.java:1180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:312) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:437) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:131) -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
I added an issue to JIRA for this: MNG-788. I described a slightly different (imho better :) ) solution. If noone objects I'll come up with a patch in the next days. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] How to turn off transitive dependencies?
Is there any way to turn off transitive dependencies? Or do I have to find the dependency which has "wrong dependencies" and explicitly exlude the "wrong" one there? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] How to turn off transitive dependencies?
Brett Porter wrote: > Currently, no there isn't a way to do this. > > I've got something on the list for beta-1 to make this possible (see > inclusions), but it is highly recommended that you track the problem and > have it fixed. We've been really reluctant to add this because > technically it shouldn't be required and because it will certainly > become a crutch and we'll stop getting feedback on bad poms. > > What are you experiencing problems with? > I don't think that this is just because of bad poms. Current in Cocoon we face two problems: 1) Avalon framework. Up to version 4.1.0 (or something) Avalon had one big jar: the avalon framework. Then starting with 4.1.1 they splitt this into two jar files: api and impl. But for convenience they provide both versions, so for example, you have avalon-framework-4.2.0.jar avalon-framework-api-4.2.0.jar avalon-framework-impl-4.2.0.jar Now Cocoon depends on 4.2.0 api and impl which of course works fine. We use several other projects, that depend on avalon-framework-4.1.5. As this is a different identifier for the jar we end up with avalon-framework-4.1.5 and api/impl from 4.2.0 resulting in errors as 4.1.5 is loaded before the other two jars! (Compilation works fine of course). All poms are imho correct. And there are several projects having these different dependencies. So everywhere specifying exclude statements can't be the solution. 2) servletapi.jar. Now, we depend on this jar, but it shouldn't go into the webapp. Fortunately this is possible and works. Unfortunately we depend on onther project that depends on the servletapi where it's not specified that the jar should not go into the webapp, because that project doesn't provide a webapp, it's just a framework. Now, you can guess what happens, we end up with the servletapi in the WEB-INF/lib directory, just because of the transitive dependency. Sure, if all poms all over the world would be correct (whatever that means) these problems can be avoided. But I don't think that this will ever really happen. Basically I think the transitive dependencies are a good idea, but I would like to turn them off and then perhaps get a warning if some dependency might be missing. In fact I think one of the biggest problems are unique identifier for artifacts. I guess you have already discussed this. As long as everyone can pick up an identifier he thinks is good, POMs will never be perfect. Look at the xml-apis mess or projects like jakarta regexp where the group id is just regexp, or projects using different ids, like avalon logkit (using just logkit, excalibur-logkit and god knows what else). So I agree that theoretically it shouldn't be required but practically it will be. :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] How to turn off transitive dependencies?
Carsten Ziegeler wrote: > 1) Avalon framework. Up to version 4.1.0 (or something) Avalon had one > big jar: the avalon framework. Then starting with 4.1.1 they splitt this > into two jar files: api and impl. But for convenience they provide both > versions, so for example, you have > avalon-framework-4.2.0.jar > avalon-framework-api-4.2.0.jar > avalon-framework-impl-4.2.0.jar > > Now Cocoon depends on 4.2.0 api and impl which of course works fine. We > use several other projects, that depend on avalon-framework-4.1.5. As > this is a different identifier for the jar we end up with > avalon-framework-4.1.5 and api/impl from 4.2.0 resulting in errors as > 4.1.5 is loaded before the other two jars! (Compilation works fine of > course). > All poms are imho correct. And there are several projects having these > different dependencies. So everywhere specifying exclude statements > can't be the solution. > Just in addition, a similar problem exists with Ant. Up to 1.5.x Ant provided two jars, ant and ant-optional. From 1.6 Ant splitted up the optinal jar into several ones. Now if your project depends on ant 1.6.5 and let's say ant-optional-trax-1.6.5 while a project you depend on, depends on ant-optional.1.5.3 again you have all three jars resulting in errors at runtime. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] How to turn off transitive dependencies?
Brett Porter wrote: > Carsten Ziegeler wrote: > > >>1) Avalon framework. Up to version 4.1.0 (or something) Avalon had one >>big jar: the avalon framework. Then starting with 4.1.1 they splitt this >>into two jar files: api and impl. But for convenience they provide both >>versions, so for example, you have >> >> > > Yep, I understand this is the case here. We're actually planning a > "supercedes" attribute in a future version so that both api and impl can > declare that they shold block an earlier version of just "framework". > Hmm, ok, this works for new releases; but I'm wondering if really all old poms will be converted and corrected. > > Absolutely - we've got the solutions in there in the cases where they > are needed, I'd just advocate considering your position first and using > them as a last resort. I think this is especially important for projects > like Cocoon where you are depended upon by lots of projects, as the > quality of your POMs affects everyone else. For example, if you block > out dependencies you think are optional but which aren't under certain > circumstances then that will affect other projects. > :) Yes, Cocoon depends on more than 130 jars; I'm trying to migrate the core of Cocoon to m2 and the core uses only about 40 jars and we are affected by several "wrong" poms. It will take ages to correct them all. As we are currently using Ant to build Cocoon, today we know exactly which libs are requried in what version - and of course Cocoon runs fine :). With m2 we loose this power. Now, don't get me wrong I really like this transitive dependency handling and it will be a great improvement, but I don't get Cocoon running just because of this :( - and we all agree that poms can always be "wrong" in one way or the other. > Anyway, I hope we've got everything necessary to help you along with this. Hmm, so what can I do today? We currently have the three problems described (avalon, servletapi and ant). Thanks Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r263841 - in /maven/components/trunk: maven-model/maven.mdo maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java
Hurray! Thanks Brett! Carsten [EMAIL PROTECTED] wrote: > Author: brett > Date: Sun Aug 28 00:18:35 2005 > New Revision: 263841 > > URL: http://svn.apache.org/viewcvs?rev=263841&view=rev > Log: > PR: MNG-788 > bring back the "filtering" attribute in resources from m1 > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Fixing problems with checksum verification
Currently you get a lot of error messages telling about a bad md5 checksum. The problem is that the md5 does not just contain the checksum itself but also the file name of the file the checksum is for. Now, what about just using the string from the md5 file upto the first space for comparision in the verifyChecksum() method of the DefaultWagonManager? This should fix the problems. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Out of memory exceptions
We get out of memory exceptions while trying to do a fresh build of Cocoon (it consists of approx 60 sub projects with several dependencies). Invoking the build after the OOM occured then builds the remaining parts of the project. Is there any way to increase the memory for m2? Is setting the usual java memory properties the right way? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Out of memory exceptions
Kenney Westerhof schrieb: > On Mon, 19 Sep 2005, Carsten Ziegeler wrote: > > Yes, set the environment variable MAVEN_OPTS; it's value is passed > as JVM arguments. > Ok, thanks > Btw this is a typical user question, you best use the users list for these > types of questions. > Yepp, you're right - sorry! Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Out of memory exceptions
Brett Porter wrote: > Though the devs are interested to hear what memory usage you were > encountering... > > Cocoon could be a good test case to see if we can reduce the amount of > memory used. > :) The more I think about it, the more I come to the conclusion that m2 might have a memory leak. I can't rebuild Cocoon in one run due to a OOM in the middle of the build, but on the second run it works. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-787) Wrong dependency handling and problems with version ranges
Wrong dependency handling and problems with version ranges -- Key: MNG-787 URL: http://jira.codehaus.org/browse/MNG-787 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-beta-1 Reporter: Carsten Ziegeler Priority: Blocker The current dependency mechanism does not use the versions specified in the POM for compilation. It uses the most recent version from some transitive dependency. An example is the xml-apis. If you specifiy e.g. version 1.3.02 in your pom, version 2.0.2 is used comming from transitive dependencies. Another problem is, as soon as you specify ranges for the version, you get an exception: If you specifiy e.g. [1.3.02] or [1.3.01,1.3.02] or [1.3.02, 1.3.03] you always get the same NPE: java.lang.NullPointerException: version was null for xml-apis:xml-apis at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:295) at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:202) at org.apache.maven.artifact.resolver.DebugResolutionListener.includeArtifact(DebugResolutionListener.java:56) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:254) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:166) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:204) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-788) Proposal for improved resource filtering
Proposal for improved resource filtering Key: MNG-788 URL: http://jira.codehaus.org/browse/MNG-788 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-beta-1 Reporter: Carsten Ziegeler The current resource filtering has to be configured at the resource plugin configuration. This issue is about making resource filtering more user-friendly. There are the following requirements: 1) being able to split resources up into two groups: the filtered-on-copy group and the 'just-copy' group. 2) being able to specify multiple properties files / having a default file so users can override. Much like project.properties/build.properties in maven1. 3) being able to specify different filter properties using profiles The last item 3) is already working, so this is about 1) and 2). What about adding the following XML to the resource section of the POM: And this configuration to the resource plugin src/build.properties.sample src/build.properties >From the following list a) and b) address item 1) while c) addresses item 2): a) As soon as a filtering section is available on a resource, it is filtered. b) Usually you have in a single resource directory resources that you want to filter and resources that shouldn't be filtered like images etc. One solution to address this is to specify two resource sets in the POM with different include and exlucde filters and turn on/off filtering accordingly. I think a more elegant way is to say, this is my resource set and filter only these files in this resource set. That's why I added the filterIncludes and filterExcludes section. We can also define default filterExcludes like images etc. On the one hand this is imho a more natural way of defining filtering and on the other hand, this should increase performance. The resource tree has only to be scanned once. With two resources, the tree is scanned twice. Especially if you have big resource trees (e.g. for webapps) this should increase performance noticeably. c) You can specify several property files at the resource plugin. This files are read in the order of appearance and if a token is defined twice, the last definition read wins. In addition you can set the failOnError flag on a property file, so if this file is missing no error occurs. I could imagine these optional additions: 4) Defining the tokens in the pom so the plugin could check which ones are missing and you have an overview of all the configuration settings used in all the resource files (the latter being more important). So, we could add this XML to the filtering section in the POM: tokenname anothertokenname If the section is missing all tokens are replaced by default. 5) Define properties directly without a property file. We could add this to the resource plugin configuration: aToken someValue ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-788) Proposal for improved resource filtering
[ http://jira.codehaus.org/browse/MNG-788?page=comments#action_45261 ] Carsten Ziegeler commented on MNG-788: -- Your description was very good, so copying it was the ideal solution (it's open source, so copying is allowed) :) Thinking about your solution wrt property files, I agree with you. Let's define a fixed set of files (project, build, build.samples) and that's it. +1 I like the description idea - this could be added by the site plugin into the docs for example. Actually, I'm not sure about your last points either - I think we should start simple and implement the first parts where we are sure and then see how the rest fits. > Proposal for improved resource filtering > > > Key: MNG-788 > URL: http://jira.codehaus.org/browse/MNG-788 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Carsten Ziegeler > > > The current resource filtering has to be configured at the resource plugin > configuration. This issue is about making resource filtering more > user-friendly. > There are the following requirements: > 1) being able to split resources up into two groups: the filtered-on-copy >group and the 'just-copy' group. > 2) being able to specify multiple properties files / having a default file > so users can override. Much like project.properties/build.properties > in maven1. > 3) being able to specify different filter properties using profiles > The last item 3) is already working, so this is about 1) and 2). > What about adding the following XML to the resource section of the POM: > > > > > And this configuration to the resource plugin > > > src/build.properties.sample > failOnError="false">src/build.properties > > > From the following list a) and b) address item 1) while c) addresses item 2): > a) As soon as a filtering section is available on a resource, it is filtered. > b) Usually you have in a single resource directory resources that you want to > filter and resources that shouldn't be filtered like images etc. One solution > to address this is to specify two resource sets in the POM with different > include and exlucde filters and turn on/off filtering accordingly. > I think a more elegant way is to say, this is my resource set and filter only > these files in this resource set. That's why I added the filterIncludes and > filterExcludes section. We can also define default filterExcludes like images > etc. On the one hand this is imho a more natural way of defining filtering > and on the other hand, this should increase performance. The resource tree > has only to be scanned once. With two resources, the tree is scanned twice. > Especially if you have big resource trees (e.g. for webapps) this should > increase performance noticeably. > c) You can specify several property files at the resource plugin. This files > are read in the order of appearance and if a token is defined twice, the last > definition read wins. In addition you can set the failOnError flag on a > property file, so if this file is missing no error occurs. > I could imagine these optional additions: > 4) Defining the tokens in the pom so the plugin >could check which ones are missing and you have an overview of >all the configuration settings used in all the resource files >(the latter being more important). >So, we could add this XML to the filtering section in the POM: > > tokenname > anothertokenname > > If the section is missing all tokens are replaced by default. > 5) Define properties directly without a property file. >We could add this to the resource plugin configuration: > > > aToken > someValue > > ... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-787) Wrong dependency handling and problems with version ranges
[ http://jira.codehaus.org/browse/MNG-787?page=comments#action_45277 ] Carsten Ziegeler commented on MNG-787: -- Retesting today without updated from the Maven svn, the NPE does not appear anymore (I guess this is due to some updates of some dependency snapshots for the compiler?). So specifying [1.3.02] or the ranges works! So I can use this as a workaround. So the only open issue is that the version specified in the POM is not used. > Wrong dependency handling and problems with version ranges > -- > > Key: MNG-787 > URL: http://jira.codehaus.org/browse/MNG-787 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Versions: 2.0-beta-1 > Reporter: Carsten Ziegeler > Priority: Blocker > > > The current dependency mechanism does not use the versions specified in the > POM for compilation. It uses the most recent version from some transitive > dependency. An example is the xml-apis. If you specifiy e.g. version 1.3.02 > in your pom, version 2.0.2 is used comming from transitive dependencies. > Another problem is, as soon as you specify ranges for the version, you get an > exception: > If you specifiy e.g. [1.3.02] or [1.3.01,1.3.02] or [1.3.02, 1.3.03] you > always get the same NPE: > java.lang.NullPointerException: version was null for xml-apis:xml-apis > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:295) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:202) > at > org.apache.maven.artifact.resolver.DebugResolutionListener.includeArtifact(DebugResolutionListener.java:56) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:275) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:254) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:166) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:204) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-788) Proposal for improved resource filtering
[ http://jira.codehaus.org/browse/MNG-788?page=comments#action_45345 ] Carsten Ziegeler commented on MNG-788: -- Sigh, and I thought this topic was easy... Anyway, it seems that we all agree to have a filtering "instruction" for a resource which turns on filtering. So what about just adding the simple element to the resource section. If the element is available the resources are filtered, if not they are not filtered. We could do this for beta-1 and can then think about how to add more instructions, either the way Brett wants it, with specifying the properties file or any other way. BUT PLEASE, let's make it configurable NOW if a resource should be filtered or not. > Proposal for improved resource filtering > > > Key: MNG-788 > URL: http://jira.codehaus.org/browse/MNG-788 > Project: Maven 2 > Type: Improvement > Components: maven-plugins > Versions: 2.0-beta-1 > Reporter: Carsten Ziegeler > Fix For: 2.0-beta-2 > > > The current resource filtering has to be configured at the resource plugin > configuration. This issue is about making resource filtering more > user-friendly. > There are the following requirements: > 1) being able to split resources up into two groups: the filtered-on-copy >group and the 'just-copy' group. > 2) being able to specify multiple properties files / having a default file > so users can override. Much like project.properties/build.properties > in maven1. > 3) being able to specify different filter properties using profiles > The last item 3) is already working, so this is about 1) and 2). > What about adding the following XML to the resource section of the POM: > > > > > And this configuration to the resource plugin > > > src/build.properties.sample > failOnError="false">src/build.properties > > > From the following list a) and b) address item 1) while c) addresses item 2): > a) As soon as a filtering section is available on a resource, it is filtered. > b) Usually you have in a single resource directory resources that you want to > filter and resources that shouldn't be filtered like images etc. One solution > to address this is to specify two resource sets in the POM with different > include and exlucde filters and turn on/off filtering accordingly. > I think a more elegant way is to say, this is my resource set and filter only > these files in this resource set. That's why I added the filterIncludes and > filterExcludes section. We can also define default filterExcludes like images > etc. On the one hand this is imho a more natural way of defining filtering > and on the other hand, this should increase performance. The resource tree > has only to be scanned once. With two resources, the tree is scanned twice. > Especially if you have big resource trees (e.g. for webapps) this should > increase performance noticeably. > c) You can specify several property files at the resource plugin. This files > are read in the order of appearance and if a token is defined twice, the last > definition read wins. In addition you can set the failOnError flag on a > property file, so if this file is missing no error occurs. > I could imagine these optional additions: > 4) Defining the tokens in the pom so the plugin >could check which ones are missing and you have an overview of >all the configuration settings used in all the resource files >(the latter being more important). >So, we could add this XML to the filtering section in the POM: > > tokenname > anothertokenname > > If the section is missing all tokens are replaced by default. > 5) Define properties directly without a property file. >We could add this to the resource plugin configuration: > > > aToken > someValue > > ... > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-73) commons-collections is missing scope
commons-collections is missing scope Key: MEV-73 URL: http://jira.codehaus.org/browse/MEV-73 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Carsten Ziegeler The dependency for junit needs the scope test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MEV-74) commons-lang is missing scope
commons-lang is missing scope - Key: MEV-74 URL: http://jira.codehaus.org/browse/MEV-74 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Carsten Ziegeler The dependency for junit needs the scope test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-811) Resource Plugin overwrites default excludes
Resource Plugin overwrites default excludes --- Key: MNG-811 URL: http://jira.codehaus.org/browse/MNG-811 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Reporter: Carsten Ziegeler As soon as you use excludes in your resources, the default excludes are overwritten. So you have to add them all "by hand" in your pom. I think this is due to a wrong call order in the resource plugin: DirectoryScanner scanner = new DirectoryScanner(); scanner.addDefaultExcludes(); ... if (excludes) scanner.setExcludes(...) Moving scanner.addDefaultExcludes() at the end of this code block solves the problem. Of course in this case you don't have a change to not use the default excludes :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-74) commons-lang is missing scope
[ http://jira.codehaus.org/browse/MEV-74?page=all ] Carsten Ziegeler closed MEV-74: --- Resolution: Fixed Thanks > commons-lang is missing scope > - > > Key: MEV-74 > URL: http://jira.codehaus.org/browse/MEV-74 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Carsten Ziegeler > > > The dependency for junit needs the scope test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-73) commons-collections is missing scope
[ http://jira.codehaus.org/browse/MEV-73?page=all ] Carsten Ziegeler closed MEV-73: --- Resolution: Fixed Thanks > commons-collections is missing scope > > > Key: MEV-73 > URL: http://jira.codehaus.org/browse/MEV-73 > Project: Maven Evangelism > Type: Bug > Components: Invalid POM > Reporter: Carsten Ziegeler > > > The dependency for junit needs the scope test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-797) fix checksum parsing
[ http://jira.codehaus.org/browse/MNG-797?page=comments#action_45613 ] Carsten Ziegeler commented on MNG-797: -- Attached is a patch that should fix the problems with md5 signatures. > fix checksum parsing > > > Key: MNG-797 > URL: http://jira.codehaus.org/browse/MNG-797 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0-beta-1 > Attachments: patch.txt > > Original Estimate: 1 hour > Remaining: 1 hour > > it currently doesn't handle whitespace around it, and should really be able > to parse the GNU and FreeBSD formats including the filename, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-797) fix checksum parsing
[ http://jira.codehaus.org/browse/MNG-797?page=all ] Carsten Ziegeler updated MNG-797: - Attachment: patch.txt > fix checksum parsing > > > Key: MNG-797 > URL: http://jira.codehaus.org/browse/MNG-797 > Project: Maven 2 > Type: Bug > Components: maven-artifact > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0-beta-1 > Attachments: patch.txt > > Original Estimate: 1 hour > Remaining: 1 hour > > it currently doesn't handle whitespace around it, and should really be able > to parse the GNU and FreeBSD formats including the filename, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
