Re: Problems with ContinuumStoreTest
Erik Drolshammer wrote: Marcelo Fukushima wrote: On 1/18/07, Erik Drolshammer [EMAIL PROTECTED] wrote: Hi! I'm trying to set up a developement environment for Continuum, but I'm experiencing some problems; *tags/continumm-1.0.3* #mvn install = log4j:WARN Please initialize the log4j system properly. Where can I configure log4j? What to configure? that message from log4j is just a warning... i dont think it should be there, but it doesnt affect your build - meaning you have a diff problem You are right. It was just horribly slow. (It hangs on log4j three times during the build). Hang on Log4j how? Any ideas on the new problem? [ERROR] BUILD ERROR [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'plexus:runtime' [0] inside the definition for plugin: 'plexus-maven-plugin'specify the following: configuration ... runtimeConfigurationPropertiesVALUE/runtimeConfigurationProperties /configuration -OR- on the command line, specify: '-DappProperties=VALUE' [INFO] Total time: 3 minutes 30 seconds If you look in the pom you can see that the value is set in two different profiles, one for test and one for production. Try running maven with -Penv-test to activate the test profile. -- Trygve
Re: handling obfuscated jars
Hi,
On 1/13/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
The last solution i can think of is to specify
classifier${obfuscate}/classifier
on all deps (in project A and B ) that can have an obfuscated attachment.
You could use a profile or -Dobfuscate=obfuscated. You just have to make sure
that not specifying to obfuscate will set the obfuscate property to the empty
string,
and that maven can handle empty classifier strings (like it does null
classifiers).
Yeah it's running fine but I am facing a very annoying problem and I'd
like to know if there is a workaround.
Here is a snippet used to handle the obfuscated thingy:
dependency
groupIdcom.foo/groupId
artifactIdbar/artifactId
version5.8.2-SNAPSHOT/version
classifier${obfuscated}/classifier
/dependency
properties
obfuscated/obfuscated
/properties
profiles
profile
idobfuscation/id
activation
property
nameobfuscated/name
valueobfuscated/value
/property
/activation
properties
obfuscatedobfuscated/obfuscated
/properties
/profile
/profiles
This is running fine if I do mvn -Dobfuscated=obfuscated. However,
activating the profile, that is mvn -Pobfuscated does not have the
expected behavior. I assume that the properties are resolved too
late to alter the dependencies. Is there a workaround to this?
BTW, will maven resolve the property (${obfuscated}) when the POM is
released? If so, this solution is kinda useless right?
Regards,
Stéphane
HTH,
-- Kenney
Stephane Nicoll wrote:
Hi,
I already discussed this with brett and Dan and I would like to see if
anyone here has more insight about how to handle obfuscated jars.
The basic use case I have is to be able to specify whether I want the
standard jars or the obfuscated jars for a particular project.
Obfuscated jars are handled as attached artifacts w/ the obfuscated
classifier.
If a particular project does not rely on any other lib that needs to
be obfuscated, everything is ok, we just depend on it with the
obfuscated classifier. The harder part is when a particular project
depends on other components that need to be obfuscated. In dev phase
it might be easier to use non obfuscated jars (as stacktraces are a
bit complex to read when something goes wrong :)
Let's say we have 3 components A, B, C. A depends on B and B depends
on C. I would like to find a way to specify bring me everything
obfuscated for A (something like intelligent classifier).
Is there anything we can do about this? The other solution is to have
a separate project for each component with the obfuscated dep, which
sounds not good at all.
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling obfuscated jars
Stephane Nicoll wrote:
Hi,
On 1/13/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
The last solution i can think of is to specify
classifier${obfuscate}/classifier
on all deps (in project A and B ) that can have an obfuscated attachment.
You could use a profile or -Dobfuscate=obfuscated. You just have to
make sure
that not specifying to obfuscate will set the obfuscate property to
the empty string,
and that maven can handle empty classifier strings (like it does null
classifiers).
Yeah it's running fine but I am facing a very annoying problem and I'd
like to know if there is a workaround.
Here is a snippet used to handle the obfuscated thingy:
dependency
groupIdcom.foo/groupId
artifactIdbar/artifactId
version5.8.2-SNAPSHOT/version
classifier${obfuscated}/classifier
/dependency
properties
obfuscated/obfuscated
/properties
profiles
profile
idobfuscation/id
activation
property
nameobfuscated/name
valueobfuscated/value
/property
/activation
properties
obfuscatedobfuscated/obfuscated
/properties
/profile
/profiles
This is running fine if I do mvn -Dobfuscated=obfuscated. However,
activating the profile, that is mvn -Pobfuscated does not have the
expected behavior. I assume that the properties are resolved too
late to alter the dependencies. Is there a workaround to this?
I think that's a bug - the properties aren't overwritten.
Try this:
add another profile with activeByDefaulttrue/activeByDefault,
and move the propertiesobfuscated//properties inside that profile.
If you don't activate the profile, that default profile should be enabled.
If you activate the obfuscation profile, then the default profile
shouldn't be activated.
BTW, will maven resolve the property (${obfuscated}) when the POM is
released?
Sure it will resolve it. What you could do is name the profile different,
there's a special profile for releases (maybe it's called 'release', not sure),
so it'll be automatically enabled when releasing (that's what you're after,
right?)
If so, this solution is kinda useless right?
I'm not following...
-- Kenney
Regards,
Stéphane
HTH,
-- Kenney
Stephane Nicoll wrote:
Hi,
I already discussed this with brett and Dan and I would like to see if
anyone here has more insight about how to handle obfuscated jars.
The basic use case I have is to be able to specify whether I want the
standard jars or the obfuscated jars for a particular project.
Obfuscated jars are handled as attached artifacts w/ the obfuscated
classifier.
If a particular project does not rely on any other lib that needs to
be obfuscated, everything is ok, we just depend on it with the
obfuscated classifier. The harder part is when a particular project
depends on other components that need to be obfuscated. In dev phase
it might be easier to use non obfuscated jars (as stacktraces are a
bit complex to read when something goes wrong :)
Let's say we have 3 components A, B, C. A depends on B and B depends
on C. I would like to find a way to specify bring me everything
obfuscated for A (something like intelligent classifier).
Is there anything we can do about this? The other solution is to have
a separate project for each component with the obfuscated dep, which
sounds not good at all.
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cmd line property is ignored - bug? (and which jira component to file in?)
Geoffrey De Smet wrote:
[based on the almost latest m2.0.5 branch]
I have this profile in my pom.xml:
profile
iddevelopment/id
activation
activeByDefaulttrue/activeByDefault
/activation
properties
no.daisy.testtrue/no.daisy.test
maven.test.skip${no.daisy.test}/maven.test.skip
/properties
/profile
So without my settings.xml mvn install doesn't run the tests.
But in my settings.xml I have a profile like this:
profile
iddaisy_1_5/id
properties
no.daisy.testfalse/no.daisy.test
...
/properties
/profile
So now mvn install does run the tests.
However when I now try
mvn -Dmaven.test.skip install
Try -Dmaven.test.skip=true.
If that fails, then you hit a known bug (search jira).
-- Kenney
The tests are still run,
while I expected my cmd line variable to overwrite my pom.xml and
setting.xml properties.
Is this a known bug? or shall I file a jira (and in which component)?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: short term branch for project/group keys
sounds good :) On 1/18/07, Rahul Thakur [EMAIL PROTECTED] wrote: Hey Jesse, I am gonna fork a new branch tonight and get started on this change. Hopefully should be able to get the relevant stuff that we have already done merged on the core modules before we start playing with the other modules tomorrow :-) Cheers, Rahul Jesse McConnell wrote: I am loathe to let a branch lay around for a long time with minimal work being done actively on it and we learned what we wanted to from it in the short time we worked with it I think. my take-away was that the change the string based keys will be a good change but its large enough that it should be done in the context of some other refactoring and changes. as for the int-long id change, I think its a good thing and will focus us to address the database upgrading issue so its all good imo :) jesse On 1/16/07, Rahul Thakur [EMAIL PROTECTED] wrote: Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
Hi Barrie, Please paste your plugin definition in your pom. not sure what you mean by that, there is not much config here. This works plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /plugin and this gives the No assembly descriptors found. error plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version executions execution id/id phase/phase goals/ configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution /executions /plugin Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
Please paste your plugin definition in your pom. not sure what you mean by that, there is not much config here. What you pasted was what I was after. This works plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /plugin and this gives the No assembly descriptors found. error plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version executions execution id/id phase/phase goals/ configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution /executions /plugin Have you removed the values in id, phase, goals for emailing? Or is that what you have defined in your pom.xml? If they are blank, then they needs values, try: execution idassemble-server/id goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution execution idassemble-client/id goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/client.xml/descriptor /descriptors /configuration /execution Then if this works, and runs the assembly for each the client.xml and server.xml you can then customize each one with the values you wanted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
Barrie, I tried with and without values, always the same error, even with your new suggestion. This is a direct copy/paste: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version executions execution idassemble-server/id goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution execution idassemble-client/id goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/client.xml/descriptor /descriptors /configuration /execution /executions /plugin Bernd Please paste your plugin definition in your pom. not sure what you mean by that, there is not much config here. What you pasted was what I was after. This works plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /plugin and this gives the No assembly descriptors found. error plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.1/version executions execution id/id phase/phase goals/ configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution /executions /plugin Have you removed the values in id, phase, goals for emailing? Or is that what you have defined in your pom.xml? If they are blank, then they needs values, try: execution idassemble-server/id goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution execution idassemble-client/id goals goalsingle/goal /goals configuration descriptors descriptorsrc/main/assembly/client.xml/descriptor /descriptors /configuration /execution Then if this works, and runs the assembly for each the client.xml and server.xml you can then customize each one with the values you wanted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
On 1/20/07, berndq [EMAIL PROTECTED] wrote: Barrie, I tried with and without values, always the same error, even with your new suggestion. descriptorsrc/main/assembly/server.xml/descriptor [del] descriptorsrc/main/assembly/client.xml/descriptor And you are sure these files exist? I have the following in my pom and it correctly runs both the bin and project assemblies: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId executions execution idassembly:package-bin/id phasepackage/phase goals !-- Work around for http://jira.codehaus.org/browse/MASSEMBLY-97 as the goal should be attached. -- goalsingle/goal /goals configuration descriptors descriptor src/main/assembly/bin.xml /descriptor /descriptors /configuration /execution execution idassembly:package-project/id phasepackage/phase goals !-- Work around for http://jira.codehaus.org/browse/MASSEMBLY-97 as the goal should be attached. -- goalsingle/goal /goals configuration descriptors !-- Available as a predefined descriptor in 2.2 -- descriptor src/main/assembly/project.xml /descriptor /descriptors /configuration /execution /executions /plugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
Barrie, And you are sure these files exist? yes D:\projekte\template\templatePom-trunkdir src\main\assembly .. 14.01.2007 11:03 884 client.xml 14.01.2007 11:04 886 server.xml remember it works without executions. Bernd I have the following in my pom and it correctly runs both the bin and project assemblies: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId executions execution idassembly:package-bin/id phasepackage/phase goals !-- Work around for http://jira.codehaus.org/browse/MASSEMBLY-97 as the goal should be attached. -- goalsingle/goal /goals configuration descriptors descriptor src/main/assembly/bin.xml /descriptor /descriptors /configuration /execution execution idassembly:package-project/id phasepackage/phase goals !-- Work around for http://jira.codehaus.org/browse/MASSEMBLY-97 as the goal should be attached. -- goalsingle/goal /goals configuration descriptors !-- Available as a predefined descriptor in 2.2 -- descriptor src/main/assembly/project.xml /descriptor /descriptors /configuration /execution /executions /plugin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
On 1/20/07, berndq [EMAIL PROTECTED] wrote: Barrie, And you are sure these files exist? I'm at a loss. Try cut and pasting my plugin config and replace each descriptor with the files for yours. Other than that I can't work out why it is not working for you and it works for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling obfuscated jars
I think that's a bug - the properties aren't overwritten.
Mmm all right.
Try this:
add another profile with activeByDefaulttrue/activeByDefault,
and move the propertiesobfuscated//properties inside that profile.
If you don't activate the profile, that default profile should be enabled.
If you activate the obfuscation profile, then the default profile
shouldn't be activated.
I don't follow but I'll try monday and I'll let you know.
BTW, will maven resolve the property (${obfuscated}) when the POM is
released?
Sure it will resolve it. What you could do is name the profile different,
there's a special profile for releases (maybe it's called 'release', not sure),
so it'll be automatically enabled when releasing (that's what you're after,
right?)
If so, this solution is kinda useless right?
I'm not following...
What I was afraid is that the released pom did not contain the
${obfuscated} string but the resolved classifier (that is the empty
string or the obfuscated string) but I think it will work properly.
I'll try your suggestion and I'll let you know. Regarding the
properties overwriting, do you want me to open an issue in Jira?
Thanks,
Stéphane
-- Kenney
Regards,
Stéphane
HTH,
-- Kenney
Stephane Nicoll wrote:
Hi,
I already discussed this with brett and Dan and I would like to see if
anyone here has more insight about how to handle obfuscated jars.
The basic use case I have is to be able to specify whether I want the
standard jars or the obfuscated jars for a particular project.
Obfuscated jars are handled as attached artifacts w/ the obfuscated
classifier.
If a particular project does not rely on any other lib that needs to
be obfuscated, everything is ok, we just depend on it with the
obfuscated classifier. The harder part is when a particular project
depends on other components that need to be obfuscated. In dev phase
it might be easier to use non obfuscated jars (as stacktraces are a
bit complex to read when something goes wrong :)
Let's say we have 3 components A, B, C. A depends on B and B depends
on C. I would like to find a way to specify bring me everything
obfuscated for A (something like intelligent classifier).
Is there anything we can do about this? The other solution is to have
a separate project for each component with the obfuscated dep, which
sounds not good at all.
Thanks,
Stéphane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: assembly plugin, multiple descriptors and manifest modifications
Hi, Yes, please open a new JIRA related to the manifest section in an assembly [external] descriptor. As for MASSEMBLY-121, could you reopen it and add a test case that is failing? I'll try to take another stab at it, if I can see what's failing. Thanks, John On 1/17/07, berndq [EMAIL PROTECTED] wrote: John, shall I open a JIRA manifest section in external descriptor? ;-) I quickly tested Barrie's suggestion but could not make it work. (I still have to verify whether I run that test correctly) Rest is OT regarding this thread Any chance that you can give me a hint why your patch for http://jira.codehaus.org/browse/MASSEMBLY-121 does not work for me? [DEBUG] maven-assembly-plugin: resolved to version 2.2-20070112.063452-32 from repository apache.org But attributes are still not in the manifest. thanks Bernd IMO, it would be cleaner if we embedded the manifest info in the assembly descriptor...then we could always support that manifest section in an external descriptor component, for shared cases... It's not available in the assembly descriptor now, but I've been thinking about that for awhile now (probably not a good idea to put it in an eventual 2.2, though). -john On 1/16/07, Barrie Treloar [EMAIL PROTECTED] wrote: On 1/16/07, berndq [EMAIL PROTECTED] wrote: Hi, I did not get an answer on the users list so I try it here: I use the assembly plugin to create multiple assemblies from a multi module project: descriptors descriptorsrc/main/assembly/server.xml/descriptor descriptorsrc/main/assembly/client.xml/descriptor /descriptors Cant you just define multiple configurations, where each configuration has the settings you want rather than lump them in the one section? Something like: plugin groupId/ artifactId/ version/ executions execution id/ phase/ goals/ configuration descriptors descriptorsrc/main/assembly/client.xml/descriptor /descriptors /configuration /execution execution id/ phase/ goals/ configuration descriptors descriptorsrc/main/assembly/server.xml/descriptor /descriptors /configuration /execution /executions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r498038 - in /maven/shared/trunk/maven-verifier/src/main/java/org/apache/maven/it/verifier: AbstractVerifier.java Verifier.java
-1
Roll that out.
Please ask was the rule we setup. Please adhere to it. You know that
I've been working on this stuff for months as I'm sure you watch the
commit logs and I posted about the problems with the ITs.
The verifier is not the place for the embedder.
The multiple invokers we have need to be collected, the multiple
verifiers need to be collected and the place the embedder is in the
final invoker. A testing tool being created from the a verifier and
invoker. If you want to help, then help us clean up the ITs first.
Jason.
On 19 Jan 07, at 5:26 PM 19 Jan 07, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Fri Jan 19 17:26:20 2007
New Revision: 498038
URL: http://svn.apache.org/viewvc?view=revrev=498038
Log:
Creating a embedder verifier
Added:
maven/shared/trunk/maven-verifier/src/main/java/org/apache/
maven/it/verifier/AbstractVerifier.java
- copied, changed from r498037, maven/shared/trunk/maven-
verifier/src/main/java/org/apache/maven/it/verifier/Verifier.java
Removed:
maven/shared/trunk/maven-verifier/src/main/java/org/apache/
maven/it/verifier/Verifier.java
Copied: maven/shared/trunk/maven-verifier/src/main/java/org/apache/
maven/it/verifier/AbstractVerifier.java (from r498037, maven/shared/
trunk/maven-verifier/src/main/java/org/apache/maven/it/verifier/
Verifier.java)
URL: http://svn.apache.org/viewvc/maven/shared/trunk/maven-verifier/
src/main/java/org/apache/maven/it/verifier/AbstractVerifier.java?
view=diffrev=498038p1=maven/shared/trunk/maven-verifier/src/main/
java/org/apache/maven/it/verifier/Verifier.javar1=498037p2=maven/
shared/trunk/maven-verifier/src/main/java/org/apache/maven/it/
verifier/AbstractVerifier.javar2=498038
==
--- maven/shared/trunk/maven-verifier/src/main/java/org/apache/
maven/it/verifier/Verifier.java (original)
+++ maven/shared/trunk/maven-verifier/src/main/java/org/apache/
maven/it/verifier/AbstractVerifier.java Fri Jan 19 17:26:20 2007
@@ -1,21 +1,24 @@
package org.apache.maven.it.verifier;
-import junit.framework.Assert;
-import org.apache.maven.it.util.FileUtils;
-import org.apache.maven.it.util.StringUtils;
-import org.apache.maven.it.util.cli.CommandLineException;
-import org.apache.maven.it.util.cli.CommandLineUtils;
-import org.apache.maven.it.util.cli.Commandline;
-import org.apache.maven.it.util.cli.StreamConsumer;
-import org.apache.maven.it.util.cli.WriterStreamConsumer;
-import org.xml.sax.InputSource;
-import org.xml.sax.SAXException;
-import org.xml.sax.SAXParseException;
-import org.xml.sax.helpers.DefaultHandler;
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
-import javax.xml.parsers.ParserConfigurationException;
-import javax.xml.parsers.SAXParser;
-import javax.xml.parsers.SAXParserFactory;
import java.io.BufferedReader;
import java.io.ByteArrayOutputStream;
import java.io.File;
@@ -41,13 +44,33 @@
import java.util.Properties;
import java.util.StringTokenizer;
+import javax.xml.parsers.ParserConfigurationException;
+import javax.xml.parsers.SAXParser;
+import javax.xml.parsers.SAXParserFactory;
+
+import junit.framework.Assert;
+
+import org.apache.maven.it.VerificationException;
+import org.apache.maven.it.Verifier;
+import org.apache.maven.it.util.FileUtils;
+import org.apache.maven.it.util.StringUtils;
+import org.apache.maven.it.util.cli.CommandLineException;
+import org.apache.maven.it.util.cli.CommandLineUtils;
+import org.apache.maven.it.util.cli.Commandline;
+import org.apache.maven.it.util.cli.StreamConsumer;
+import org.apache.maven.it.util.cli.WriterStreamConsumer;
+import org.xml.sax.InputSource;
+import org.xml.sax.SAXException;
+import org.xml.sax.SAXParseException;
+import org.xml.sax.helpers.DefaultHandler;
+
/**
* @author a href=mailto:[EMAIL PROTECTED]Jason van Zyl /a
* @author a href=mailto:[EMAIL PROTECTED]Brett Porter/a
* @version $Id$
* @noinspection UseOfSystemOutOrSystemErr,RefusedBequest
*/
-public class Verifier
+public abstract class AbstractVerifier
{
private static final String LOG_FILENAME = log.txt;
@@ -74,13 +97,13 @@
private boolean debug;
-public Verifier( String basedir, String
Re: short term branch for project/group keys
I am done with my changes on 'id-refactor' branch. The tests run fine without any errors. It would be great if others can take this for a spin as well. How does this gets merged back to trunk now? vote? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Saturday, January 20, 2007 5:11 AM Subject: Re: short term branch for project/group keys sounds good :) On 1/18/07, Rahul Thakur [EMAIL PROTECTED] wrote: Hey Jesse, I am gonna fork a new branch tonight and get started on this change. Hopefully should be able to get the relevant stuff that we have already done merged on the core modules before we start playing with the other modules tomorrow :-) Cheers, Rahul Jesse McConnell wrote: I am loathe to let a branch lay around for a long time with minimal work being done actively on it and we learned what we wanted to from it in the short time we worked with it I think. my take-away was that the change the string based keys will be a good change but its large enough that it should be done in the context of some other refactoring and changes. as for the int-long id change, I think its a good thing and will focus us to address the database upgrading issue so its all good imo :) jesse On 1/16/07, Rahul Thakur [EMAIL PROTECTED] wrote: Jesse and myself had a chat yesterday morning about the key-refactoring branch that we spun before Christmas last year, and we reckon that it might be an idea to get 1.1-alpha rolling and meantime gather more thoughts around Groupings (introduce versions/tags). We think having String-based keys for groups might be more feasible for v1.2. However, we are keen to bring over the API changes where the 'int' Ids are now converted to 'long'. Some other bits like breaking up the existing Project and ProjectGroup interfaces can be continued on the trunk itself after the merge. What do others think? Cheers, Rahul - Original Message - From: Jesse McConnell [EMAIL PROTECTED] To: continuum-dev@maven.apache.org Sent: Friday, December 22, 2006 8:30 AM Subject: short term branch for project/group keys I am thinking about pulling a short term branch of continuum with rahul and working on getting everything converted to using a string based key project and project group reference in all apis and in all of the UI decision making items. He has tomorrow off so I think that unless anyone has any big issues with it we'll try and make that branch and work on it tomorrow. the end result of it would be: * int id's for project and project group in the model are for internal store usage * name's for project and project group are for presentation purposes only * key's are for all api usage and passing around un URL's etc. some quick benefits are: * consistency across all apis and url manipulations * ability to add quick url rewriting for direct linking of projects foo.org/Doxia/Core * common keys across running continuum instances for clustering jesse -- jesse mcconnell [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
maven-metadata xml schema?
Is there a xml schema available for maven-metadata.xml files? Thanks, - Ole Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-metadata xml schema?
I'm not positive, but I don't think so. I think that all of the schemas are in http://maven.apache.org/xsd/ and I don't see it there. On 1/19/07, Ole Ersoy [EMAIL PROTECTED] wrote: Is there a xml schema available for maven-metadata.xml files? Thanks, - Ole Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Kick [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
